Discussion:
Processed: Re: Bug#893251: jabref 3.8 is started with OpenJDK 9 instead of 8
(too old to reply)
Debian Bug Tracking System
2018-03-17 18:30:01 UTC
Permalink
forcemerge 890905 -1
Bug #890905 [jabref] jabref: doesn't build/run with default-jdk/-jre
Bug #893251 [jabref] jabref 3.8 is started with OpenJDK 9 instead of 8
Set Bug forwarded-to-address to 'https://github.com/JabRef/jabref/issues/2594'.
Severity set to 'serious' from 'important'
Added tag(s) upstream, patch, and pending.
Merged 890905 893251
--
890905: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890905
893251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893251
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
gregor herrmann
2018-03-18 15:40:02 UTC
Permalink
Control: clone 890905 -1
Control: retitle -1 jabref: doesn't start with liblog4j2-java 2.10.0-1
Control: tag -1 - patch pending
Dear Gregor,
thank you very much for your fast reply.
You're welcome.
True, this is already reported as #890905/#893138.
I ('m trying to) merge those two bugs.
Sorry, for reporting again. I noticed that bugs. But as a
Java-foreigner it wasn't clear for me if they address the same issue.
No worries.
You can run
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ jabref
Something is wrong here. Did openjdk-8 changed a bit?
Hm ...
$ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ jabref
java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; at
org.apache.logging.log4j.core.appender.OutputStreamManager.flushBuffer(OutputStreamManager.java:292)
at
org.apache.logging.log4j.core.appender.OutputStreamManager.flush(OutputStreamManager.java:303)
at
org.apache.logging.log4j.core.appender.OutputStreamManager.closeOutputStream(OutputStreamManager.java:308)
at
org.apache.logging.log4j.core.appender.OutputStreamManager.releaseSub(OutputStreamManager.java:137)
at
org.apache.logging.log4j.core.appender.AbstractManager.stop(AbstractManager.java:86)
at
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.stop(AbstractOutputStreamAppender.java:142)
at
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.stop(AbstractOutputStreamAppender.java:136)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.stop(AbstractConfiguration.java:359)
at
org.apache.logging.log4j.core.AbstractLifeCycle.stop(AbstractLifeCycle.java:136)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:550)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:122)
at
org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:39)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at
org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:40)
at
org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:55)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655) at
net.sf.jabref.JabRefMain.<clinit>(JabRefMain.java:37)
Ouch, I have to confirm that I get the same errors.

Maybe that's caused by the recent update of liblog4j2-java 2.8.2-2 -> 2.10.0-1

Indeed, downgrading liblog4j2-java to 2.8.2-2 helps.

Not sure if this is a jabref problem or a liblog4j2-java issue; let's
hope the java experts can shed some light on this bug.


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: Cat Stevens: On The Road To Find Out
Debian Bug Tracking System
2018-03-18 15:40:02 UTC
Permalink
Post by gregor herrmann
clone 890905 -1
Bug #890905 [jabref] jabref: doesn't build/run with default-jdk/-jre
Bug #893251 [jabref] jabref 3.8 is started with OpenJDK 9 instead of 8
Failed to clone 890905: Bug is marked as being merged with others. Use an existing clone.
Post by gregor herrmann
retitle -1 jabref: doesn't start with liblog4j2-java 2.10.0-1
Bug #893251 [jabref] jabref 3.8 is started with OpenJDK 9 instead of 8
Bug #890905 [jabref] jabref: doesn't build/run with default-jdk/-jre
Changed Bug title to 'jabref: doesn't start with liblog4j2-java 2.10.0-1' from 'jabref 3.8 is started with OpenJDK 9 instead of 8'.
Changed Bug title to 'jabref: doesn't start with liblog4j2-java 2.10.0-1' from 'jabref: doesn't build/run with default-jdk/-jre'.
Post by gregor herrmann
tag -1 - patch pending
Bug #893251 [jabref] jabref: doesn't start with liblog4j2-java 2.10.0-1
Bug #890905 [jabref] jabref: doesn't start with liblog4j2-java 2.10.0-1
Removed tag(s) patch and pending.
Removed tag(s) pending and patch.
--
890905: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890905
893251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893251
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
tony mancill
2018-03-20 05:50:01 UTC
Permalink
Post by gregor herrmann
You can run
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ jabref
Something is wrong here. Did openjdk-8 changed a bit?
Hm ...
$ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ jabref
java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; at
org.apache.logging.log4j.core.appender.OutputStreamManager.flushBuffer(OutputStreamManager.java:292)
at
org.apache.logging.log4j.core.appender.OutputStreamManager.flush(OutputStreamManager.java:303)
at
org.apache.logging.log4j.core.appender.OutputStreamManager.closeOutputStream(OutputStreamManager.java:308)
at
org.apache.logging.log4j.core.appender.OutputStreamManager.releaseSub(OutputStreamManager.java:137)
at
org.apache.logging.log4j.core.appender.AbstractManager.stop(AbstractManager.java:86)
at
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.stop(AbstractOutputStreamAppender.java:142)
at
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.stop(AbstractOutputStreamAppender.java:136)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.stop(AbstractConfiguration.java:359)
at
org.apache.logging.log4j.core.AbstractLifeCycle.stop(AbstractLifeCycle.java:136)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:550)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:122)
at
org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:39)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at
org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:40)
at
org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:55)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655) at
net.sf.jabref.JabRefMain.<clinit>(JabRefMain.java:37)
Ouch, I have to confirm that I get the same errors.
Maybe that's caused by the recent update of liblog4j2-java 2.8.2-2 -> 2.10.0-1
Indeed, downgrading liblog4j2-java to 2.8.2-2 helps.
Not sure if this is a jabref problem or a liblog4j2-java issue; let's
hope the java experts can shed some light on this bug.
Ouch indeed! I'm pretty certain that this is an issue with how
liblog4j2-java is being built for Debian. There is some discussion of
the issue here [1]. Basically, we need to take precautions when
building libraries with JDK 9 that are expected to run with JDK 8
runtimes.

That said, so far I'm not able to build a liblog4j2-java from the
2.10.0-1 source package that will play nicely with jabref, but I'll keep
looking at that and other options (aside from suggesting that we start
recommending a stretch chroot for jabref...)

Cheers,
tony

[1] https://github.com/plasma-umass/doppio/issues/497
gregor herrmann
2018-03-20 23:00:02 UTC
Permalink
Post by tony mancill
Post by gregor herrmann
Maybe that's caused by the recent update of liblog4j2-java 2.8.2-2 -> 2.10.0-1
Indeed, downgrading liblog4j2-java to 2.8.2-2 helps.
Not sure if this is a jabref problem or a liblog4j2-java issue; let's
hope the java experts can shed some light on this bug.
Ouch indeed! I'm pretty certain that this is an issue with how
liblog4j2-java is being built for Debian. There is some discussion of
the issue here [1]. Basically, we need to take precautions when
building libraries with JDK 9 that are expected to run with JDK 8
runtimes.
Thanks for looking into this issue and for digging up this reference.
Post by tony mancill
That said, so far I'm not able to build a liblog4j2-java from the
2.10.0-1 source package that will play nicely with jabref, but I'll keep
looking at that and other options (aside from suggesting that we start
recommending a stretch chroot for jabref...)
Thanks. And I'm optimistic that you'll succeed in the end :)

Should we reassign this bug to liblog4j2-java (+ affects jabref)? I
suppose the problem doesn't exclusively hit jabref?
Post by tony mancill
[1] https://github.com/plasma-umass/doppio/issues/497
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: Rebekka Bakken & Wolfgang Muthspiel: Nowhere
Emmanuel Bourg
2018-04-06 09:20:01 UTC
Permalink
Post by gregor herrmann
Post by tony mancill
That said, so far I'm not able to build a liblog4j2-java from the
2.10.0-1 source package that will play nicely with jabref, but I'll keep
looking at that and other options (aside from suggesting that we start
recommending a stretch chroot for jabref...)
Thanks. And I'm optimistic that you'll succeed in the end :)
Should we reassign this bug to liblog4j2-java (+ affects jabref)? I
suppose the problem doesn't exclusively hit jabref?
I've uploaded liblog4j2-java/2.10.0-2 that should work with Java 8.
Could you give it a try?

Emmanuel Bourg
gregor herrmann
2018-04-06 18:00:01 UTC
Permalink
Control: tag -1 + pending
Post by Emmanuel Bourg
Post by gregor herrmann
Should we reassign this bug to liblog4j2-java (+ affects jabref)? I
suppose the problem doesn't exclusively hit jabref?
I've uploaded liblog4j2-java/2.10.0-2 that should work with Java 8.
Could you give it a try?
That's excellent news, thank you!

Let me try ...

During build I see some scary output:

Malformed class file [module-info.class] in jar [/usr/share/maven-repo/org/apache/logging/log4j/log4j-api/debian/log4j-api-debian.jar] found on classpath, which means that this class will cause a compile error if referenced in a source file. Gradle 5.0 will no longer allow malformed classes on compile classpath.
at org.gradle.api.internal.changedetection.state.JvmClassHasher.visit(JvmClassHasher.java:154)
at org.gradle.api.internal.changedetection.state.JvmClassHasher.hashJarFile(JvmClassHasher.java:122)
at org.gradle.api.internal.changedetection.state.DefaultCompileClasspathSnapshotter.normaliseFileElement(DefaultCompileClasspathSnapshotter.java:75)
at org.gradle.api.internal.changedetection.state.AbstractFileCollectionSnapshotter$FileCollectionVisitorImpl.visitCollection(AbstractFileCollectionSnapshotter.java:144)
at org.gradle.api.internal.file.AbstractFileCollection.visitRootElements(AbstractFileCollection.java:234)
at org.gradle.api.internal.file.CompositeFileCollection.visitRootElements(CompositeFileCollection.java:185)
at org.gradle.api.internal.changedetection.state.AbstractFileCollectionSnapshotter.snapshot(AbstractFileCollectionSnapshotter.java:71)
at org.gradle.api.internal.changedetection.rules.AbstractNamedFileSnapshotTaskStateChanges.buildSnapshots(AbstractNamedFileSnapshotTaskStateChanges.java:87)
at org.gradle.api.internal.changedetection.rules.AbstractNamedFileSnapshotTaskStateChanges.<init>(AbstractNamedFileSnapshotTaskStateChanges.java:54)
at org.gradle.api.internal.changedetection.rules.InputFilesTaskStateChanges.<init>(InputFilesTaskStateChanges.java:28)
at org.gradle.api.internal.changedetection.rules.TaskUpToDateState.<init>(TaskUpToDateState.java:55)
at org.gradle.api.internal.changedetection.changes.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.getStates(DefaultTaskArtifactStateRepository.java:164)
at org.gradle.api.internal.changedetection.changes.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.isUpToDate(DefaultTaskArtifactStateRepository.java:79)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:51)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:236)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:228)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:61)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:228)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:77)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:58)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

but the build finishes.

At runtime, I see no single warning related to log4j, and jabref just
starts - yay \o/


Cheers,
gregor, uploading in a minute
--
.''`. 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: Peter Jones: Heart Labour
Debian Bug Tracking System
2018-04-06 18:00:01 UTC
Permalink
Post by gregor herrmann
tag -1 + pending
Bug #893251 [jabref] jabref: doesn't start with liblog4j2-java 2.10.0-1
Bug #894106 [jabref] jabref: fails to start with java-8-openjdk-amd64
Added tag(s) pending.
Added tag(s) pending.
--
893251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893251
894106: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894106
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
c***@posteo.jp
2018-03-19 20:40:02 UTC
Permalink
Dear Gregor,

thank you very much for your fast reply.
True, this is already reported as #890905/#893138.
I ('m trying to) merge those two bugs.
Sorry, for reporting again. I noticed that bugs. But as a
Java-foreigner it wasn't clear for me if they address the same issue.
You can run
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ jabref
Something is wrong here. Did openjdk-8 changed a bit?

$ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ jabref
Exception in thread "main" java.lang.NoSuchMethodError:
java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; at
org.apache.logging.log4j.core.appender.OutputStreamManager.flushBuffer(OutputStreamManager.java:292)
at
org.apache.logging.log4j.core.appender.OutputStreamManager.flush(OutputStreamManager.java:303)
at
org.apache.logging.log4j.core.appender.OutputStreamManager.closeOutputStream(OutputStreamManager.java:308)
at
org.apache.logging.log4j.core.appender.OutputStreamManager.releaseSub(OutputStreamManager.java:137)
at
org.apache.logging.log4j.core.appender.AbstractManager.stop(AbstractManager.java:86)
at
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.stop(AbstractOutputStreamAppender.java:142)
at
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.stop(AbstractOutputStreamAppender.java:136)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.stop(AbstractConfiguration.java:359)
at
org.apache.logging.log4j.core.AbstractLifeCycle.stop(AbstractLifeCycle.java:136)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:550)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:122)
at
org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:39)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at
org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:40)
at
org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:55)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655) at
net.sf.jabref.JabRefMain.<clinit>(JabRefMain.java:37)
Loading...