After installing the Linux version of the system from the .deb file it is necessary to make a change to a configuration file for the system to run.
The work around for now is to include the following hack in the installation instructions for Linux:
$ sudo sed -i "s|app.runtime=.*|app.runtime=$JAVA_HOME|g" /opt/VocabHunter/app/VocabHunter.cfg
I've asked for help with this problem on Stack Overflow: http://stackoverflow.com/questions/35826939
@AdamCarroll Has this problem been resolved yet?
@JerJohn15 no. Take a look at FibreFoX/javafx-gradle-plugin#43 for a discussion of the problem. Basically it boils down to a bug in the JDK: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8163356
Just to say, this is no real bug, it is just some inconvenience, but might be solved via the installer itself (at least when having .deb-installers. I will fiddle a bit with the installer-scripts to have the JRE_HOME-variable being set in the case it does not exist. The "workaround" for setting the runtime-variable inside the .cfg file might even be part of the installer ;) will report back next week after I found something.
Wow, that sounds like good news! I look forward to hearing how you get on next week.
I guess the problem that you might have with the JAVA_HOME workaround is that it just shifts the problem from JRE_HOME to JAVA_HOME. But a bare Linux installation with Java installed may not have those variables at all.
Hi @AdamCarroll , on debian all startup-scripts I have seen are not looking for the JAVA_HOME-variable (nor JRE_HOME), they are looking for some known paths (or just looking at /usr/bin/java). Never done something with deb-packaging, but it might be worth a try.
Yes, an approach that uses known paths seems to me to be more likely to work given that it seems that the Java installers are not setting the environment variables. I suppose the problem might then be to ensure that you know all the right places to search and also what to do on systems with more than one JRE.
Hi @AdamCarroll, that scenario (multiple paths to JREs) wouldn't be such a problem, because the file at /usr/bin/java is some symlink being updated via update-alternatives, so end-users will have to make sure to their system is setup correctly. There needs some installation-instructions like having oracle-java8-set-default being installed too, not only oracle-java8-installer.
I will try to make something like this:
However, there is one problem with the last step: if the end-user chooses to change the installed JRE/JDK (like switching from OpenJDK to OracleJDK), this won't be detected, at least I currently don't know what the behaviour should be ...
But all in all, this would be a big improvement compared to the current state ;) how does this sound to you?
@FibreFoX That sounds like a really good solution! I like the way that there is a clear fallback behviour to find the JRE in a "known location" but that the user can override this with an environment variable. I agree - it would be a big improvement.
Thanks to @FibreFoX for providing a fix to this problem! The fix will go live in the next release (hopefully in the next couple of weeks) and I'll close the issue then.
This fix is now live in release 1.0.18 of VocabHunter