Bug#900356: jabref: JabRef does no longer start with Java8

2018-06-18 Thread gregor herrmann
On Sun, 17 Jun 2018 21:47:09 -0700, tony mancill wrote:

> For the time-being, I propose that we check the java version directly in
> the jabref wrapper script like so:
> 
> JAVA_VERSION=$(run_java -version 2>&1 | grep ' version ' | awk '{print $3}')
> if ! ( echo "$JAVA_VERSION" | grep -q '1.8.0' ) ; then
> # We need some options to start this version on openjdk9 and later
> JABREF_JAVA_OPTS=${JABREF_JAVA_OPTS-"--add-modules=java.se.ee ...}
> fi

Looks good.
 
> This works for all of my desk-tests and the updated jabref-wrapper has
> been pushed to packaging repo.  If I don't hear any concerns, I'll
> upload this week.

Great, thank you!


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: Led Zeppelin: Darlene


signature.asc
Description: Digital Signature


Bug#900356: jabref: JabRef does no longer start with Java8

2018-06-17 Thread tony mancill
On Sat, Jun 02, 2018 at 07:06:56PM +0200, gregor herrmann wrote:
> On Sat, 02 Jun 2018 09:59:55 -0700, tony mancill wrote:
> 
> > What I think we should do is try to detect if the jabref-wrapper is
> > being invoked with java8 and clear the options required for the java9
> > workaround.
> > If that sounds acceptable, I'll work on that.  (I should have done
> > something like that in the first place.)
> 
> Thanks, that was indeed my other idea :)

I took a close look at this and it could work in the simple case with
something like:

if find_java_runtime java9 ; then
# We need some options to start this version on openjdk9 and later
JABREF_JAVA_OPTS=${JABREF_JAVA_OPTS-"--add-modules=java.se.ee ...}
else
find_java_runtime java8
fi

However, $(find_java_runtime java9) will happily return true if
JAVA_HOME, JAVA_CMD, or JAVA_BINDIR are set, regardless of what version
the function "finds," and so logic will fail if JAVA_HOME is set in the
user's environment (which I think is pretty common).

We could pretty easily extend java-wrappers with a new function that
invokes "java -version" to set a new variable, say JAVA_RUNTIME_VERSION,
but I would like to give that lot of testing before pushing such change.

For the time-being, I propose that we check the java version directly in
the jabref wrapper script like so:

JAVA_VERSION=$(run_java -version 2>&1 | grep ' version ' | awk '{print $3}')
if ! ( echo "$JAVA_VERSION" | grep -q '1.8.0' ) ; then
# We need some options to start this version on openjdk9 and later
JABREF_JAVA_OPTS=${JABREF_JAVA_OPTS-"--add-modules=java.se.ee ...}
fi

This works for all of my desk-tests and the updated jabref-wrapper has
been pushed to packaging repo.  If I don't hear any concerns, I'll
upload this week.

Cheers,
tony


signature.asc
Description: PGP signature


Bug#900356: jabref: JabRef does no longer start with Java8

2018-06-02 Thread gregor herrmann
On Sat, 02 Jun 2018 09:59:55 -0700, tony mancill wrote:

> > Looking at the recent evolution of debian/control, I note that
> > there's no default-jre or openjdk-* in Depends any more.
> > 
> > The recent changes were:
> > "default-jre (>= 2:1.8) | java8-runtime" → "openjdk-8-jre" → ""
> > 
> > I guess, adding something like
> > "default-jre (>= 2:1.9) | java9-runtime"
> > should help (java9-runtime is provided by default-jre (2:1.10-65),
> > default-jre (2:1.10-66), openjdk-10-jre (10.0.1+10-4), openjdk-11-jre
> > (11~13-2), openjdk-11-jre (11~15-1), openjdk-9-jre (9.0.4+12-4)).
> > 
> > Tony, what do you think?
> I'm not sure about requiring java9-runtime given that our users
> obviously run JREs other than the default in the current distribution.

Good point.
(Although technicall any java runtime is required I guess.)

> What I think we should do is try to detect if the jabref-wrapper is
> being invoked with java8 and clear the options required for the java9
> workaround.
> If that sounds acceptable, I'll work on that.  (I should have done
> something like that in the first place.)

Thanks, that was indeed my other idea :)
  

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: Eric Clapton: Lay Down Sally


signature.asc
Description: Digital Signature


Bug#900356: jabref: JabRef does no longer start with Java8

2018-06-02 Thread tony mancill
On Tue, May 29, 2018 at 04:40:50PM +0200, gregor herrmann wrote:
> On Tue, 29 May 2018 14:41:14 +0200, Andreas Gocht wrote:
> 
> > I recently tried to start JabRef using my default Java8 version. I got the 
> > following error:
> > 
> > Unrecognized option: --add-modules=java.se.ee
> > Error: Could not create the Java Virtual Machine.
> > Error: A fatal exception has occurred. Program will exit.
> > 
> > I realised, that --add-modules=java.se.ee might be needed for Java9, so I 
> > installed openjdk-9-jre which solved the problem.
> 
> Thanks for your bug report!
> 
> Indeed, the interaction between JabRef and various openjdk-* versions
> is a bit messy.
> 
> Looking at the recent evolution of debian/control, I note that
> there's no default-jre or openjdk-* in Depends any more.
> 
> The recent changes were:
> "default-jre (>= 2:1.8) | java8-runtime" → "openjdk-8-jre" → ""
> 
> I guess, adding something like
> "default-jre (>= 2:1.9) | java9-runtime"
> should help (java9-runtime is provided by default-jre (2:1.10-65),
> default-jre (2:1.10-66), openjdk-10-jre (10.0.1+10-4), openjdk-11-jre
> (11~13-2), openjdk-11-jre (11~15-1), openjdk-9-jre (9.0.4+12-4)).
> 
> Tony, what do you think?

I'm not sure about requiring java9-runtime given that our users
obviously run JREs other than the default in the current distribution.
What I think we should do is try to detect if the jabref-wrapper is
being invoked with java8 and clear the options required for the java9
workaround.

If that sounds acceptable, I'll work on that.  (I should have done
something like that in the first place.)
 
> PS and JFTR: `JABREF_JAVA_OPTS="" jabref' might have worked with
> openjdk-8 as well.

Yes, the intention in allowing JABREF_JAVA_OPTS to be overridden on the
command-line was to support JREs that don't play nicely with the
workarounds required for the default JRE shipped by default in Debian.

Cheers,
tony 


signature.asc
Description: PGP signature


Bug#900356: jabref: JabRef does no longer start with Java8

2018-05-29 Thread gregor herrmann
On Tue, 29 May 2018 14:41:14 +0200, Andreas Gocht wrote:

> I recently tried to start JabRef using my default Java8 version. I got the 
> following error:
> 
> Unrecognized option: --add-modules=java.se.ee
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> I realised, that --add-modules=java.se.ee might be needed for Java9, so I 
> installed openjdk-9-jre which solved the problem.

Thanks for your bug report!

Indeed, the interaction between JabRef and various openjdk-* versions
is a bit messy.

Looking at the recent evolution of debian/control, I note that
there's no default-jre or openjdk-* in Depends any more.

The recent changes were:
"default-jre (>= 2:1.8) | java8-runtime" → "openjdk-8-jre" → ""

I guess, adding something like
"default-jre (>= 2:1.9) | java9-runtime"
should help (java9-runtime is provided by default-jre (2:1.10-65),
default-jre (2:1.10-66), openjdk-10-jre (10.0.1+10-4), openjdk-11-jre
(11~13-2), openjdk-11-jre (11~15-1), openjdk-9-jre (9.0.4+12-4)).

Tony, what do you think?


PS and JFTR: `JABREF_JAVA_OPTS="" jabref' might have worked with
openjdk-8 as well.
 

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: Bruce Springsteen: The Fuse


signature.asc
Description: Digital Signature


Bug#900356: jabref: JabRef does no longer start with Java8

2018-05-29 Thread Andreas Gocht
Package: jabref
Version: 3.8.2+ds-5
Severity: normal

Dear Maintainer,

I recently tried to start JabRef using my default Java8 version. I got the 
following error:

Unrecognized option: --add-modules=java.se.ee
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

I realised, that --add-modules=java.se.ee might be needed for Java9, so I 
installed openjdk-9-jre which solved the problem.

Just for completnes the output of DEBUG_WRAPPER=1 jabref --debug and dpkg -l 
"openjdk*" before and after the update to java9:

## Before Update 

# DEBUG_WRAPPER=1 jabref --debug
[debug] /usr/bin/jabref: Found JAVA_HOME = '/usr/lib/jvm/java-8-openjdk-amd64'
[debug] /usr/bin/jabref: Found JAVA_CMD = 
'/usr/lib/jvm/java-8-openjdk-amd64/bin/java'
[debug] /usr/bin/jabref: Environment variable CLASSPATH is ''
[debug] /usr/bin/jabref: Runnning /usr/lib/jvm/java-8-openjdk-amd64/bin/java  
-classpath 
/usr/share/java/jabref.jar:/usr/share/java/bcprov.jar:/usr/share/java/antlr3-runtime.jar:/usr/share/java/antlr4-runtime.jar:/usr/share/java/com.android.json.jar:/usr/share/java/commons-cli.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-lang3.jar:/usr/share/java/commons-logging.jar:/usr/share/java/fontbox.jar:/usr/share/java/glazedlists.jar:/usr/share/java/guava.jar:/usr/share/java/httpasyncclient.jar:/usr/share/java/httpclient.jar:/usr/share/java/httpcore.jar:/usr/share/java/httpcore-nio.jar:/usr/share/java/httpmime.jar:/usr/share/java/java-string-similarity.jar:/usr/share/java/jempbox.jar:/usr/share/java/jgoodies-common.jar:/usr/share/java/jgoodies-forms.jar:/usr/share/java/jgoodies-looks.jar:/usr/share/java/jhlabs-filters.jar:/usr/share/java/jsoup.jar:/usr/share/java/juh.jar:/usr/share/java/jurt.jar:/usr/share/java/log4j-api.jar:/usr/share/java/log4j-core.jar:/usr/share/java/log4j-jcl.jar:/usr/share/java/microba.jar:/usr/share/java/mysql-connector-java.jar:/usr/share/java/pdfbox.jar:/usr/share/java/postgresql.jar:/usr/share/java/ridl.jar:/usr/share/java/spin.jar:/usr/share/java/swingx.jar:/usr/share/java/swing-layout.jar:/usr/share/java/unirest-java.jar:/usr/share/java/unoil.jar
 --add-modules=java.se.ee --add-opens=java.desktop/java.awt=ALL-UNNAMED 
net.sf.jabref.JabRefMain --debug
Unrecognized option: --add-modules=java.se.ee
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

# dpkg -l "openjdk*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   
  ArchitectureDescription
+++-=-===-===-
un  openjdk-6-jre 
(no description 
available)
un  openjdk-6-jre-headless
(no description 
available)
rc  openjdk-7-jre-headless:amd64  
7u111-2.6.7-2~deb8u1amd64   OpenJDK 
Java runtime, using Hotspot JIT (headless)
un  openjdk-7-jre-lib 
(no description 
available)
un  openjdk-8-demo
(no description 
available)
ii  openjdk-8-jdk:amd64   8u171-b11-2   
  amd64   OpenJDK Development 
Kit (JDK)
ii  openjdk-8-jdk-headless:amd64  8u171-b11-2   
  amd64   OpenJDK Development 
Kit (JDK) (headless)
ii  openjdk-8-jre:amd64   8u171-b11-2   
  amd64   OpenJDK Java runtime, 
using Hotspot JIT
ii  openjdk-8-jre-headless:amd64  8u171-b11-2   
  amd64   OpenJDK Java runtime, 
using Hotspot JIT (headless)
un  openjdk-8-source  
(no description 
available)

# After Update ###

# DEBUG_WRAPPER=1 jabref --debug
[debug] /usr/bin/jabref: Picking up the JVM designated by the alternatives 
system: 
[debug] /usr/bin/jabref:   JAVA_HOME = '/usr/lib/jvm/java-9-openjdk-amd64'