Update Hatch Java / Javafx versions

Bug #1817932 reported by Bill Erickson on 2019-02-27
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned

Bug Description

Spawned from bug #1741299, since this requires additional discussion.

As noted in bug #1741299, a bug in the JavaFX 1.8 code prevents Dymo (or other small-paper) printers from working. This bug is resolved in JavaFX versions 1.9 and above. I did my testing on Java 1.11 from https://jdk.java.net/11/. I tested both Linux and Windows bundles.

Given licensing funkiness with newer Java versions, we may have to change how we deploy the code. Note the downloads from jdk.java.net are GPL-licensed, but they do not include installers, just zip files of pre-built binaries.

Documentation on my test setup to follow.

Bill Erickson (berick) wrote :

This is how I tested in Linux. The same general procedures apply to Windows, assuming you fetch Windows binaries instead, of course, and manually install the JSON jar file.

The Hatch working branch applies a minor deprecation fix for jdk 11 and modifies hatch.sh and hatch.bat to look for the jdk 11 files in the local directory.

======
git clone git.evergreen-ils.org:Hatch.git
cd Hatch
git remote add working git.evergreen-ils.org:working/Hatch.git
git fetch working
git checkout -b user/berick/lp1817932-jdk11 working/user/berick/lp1741299-jdk11

wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
wget https://download2.gluonhq.com/openjfx/11.0.2/openjfx-11.0.2_linux-x64_bin-sdk.zip
tar -zxf openjdk-11.0.2_linux-x64_bin.tar.gz
unzip openjfx-11.0.2_linux-x64_bin-sdk.zip

# hatch.sh assumes ./jdk-11 and ./javafx-sdk-11
mv jdk-11.0.2 jdk-11
mv javafx-sdk-11.0.2 javafx-sdk-11

./hatch.sh compile
./hatch.sh test
=====

Some questions:

1. Do we want to bundle Java and JavaFX binaries in with Hatch for deployment instead of requiring it be installed in advance? This gives us a lot of control and simplicity, but requires we monitor and create Hatch installer builds for java security updates.

2. Does the licence even allow bundling? I think so, but more eyes required.

From the download site:

"This page provides production-ready open-source builds of the Java Development Kit, version 11.0.2, an implementation of the Java SE 11.0.2 Platform under the GNU General Public License, version 2, with the Classpath Exception."

https://openjdk.java.net/legal/gplv2+ce.html

Note the OpenJFX files use the same license, but the builds are provided by a third-party. See https://openjfx.io/ for more.

Jason Boyer (jboyer) wrote :

Given how many lines of hatch.bat are just for cycling through all of the possible paths that Java may be hiding in and all of that nsi code that does the same, I'm 1000% for including everything you need in a single installer. (Especially if we can narrow down which jars we actually need vs "everything.")

Also, it would be better from the end user point of view if they only have to install 1 thing and they're done.

As far as licensing goes, since it's GPL2 + an exception I don't see where we would run into any issues since Hatch is also GPL2 and wouldn't even make use of the exception. (The purpose of which appears to be to allow you to link to GPL2 Java libs without also making your whole app GPL2.) I'm obviously no lawyer but that's how I read it.

Bill Erickson (berick) wrote :

Thanks, Jason.

It also occurs to me avoiding a proper Java install, where executables and libraries are made available to other applications, reduces exposure to potential Java security threats.

And there's the benefit of not preventing users from installing Java on their own if needed without concern for clobbering the version required by Hatch.

Blake GH (bmagic) wrote :

Bundling Java and JavaFX sounds like a fine idea. +1

Geoff Sams (gsams) wrote :

You've got my +1!

I agree with Jason as far as licensing is concerned. I think this project is well within those considerations.

Bill Erickson (berick) wrote :

Getting started with a Linux script to fetch openjdk/openjfx/json Linux/Windows dependencies and put them in a well-known location within the Hatch directory. Also updates the hatch.sh and hatch.bat files to reference the new file paths.

https://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/berick/lp1817932-jdk11

TODO:
 Update the windows exe builder and docs to accommodate these changes.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Kyle Huckins (khuckins) on 2019-03-21
Changed in evergreen:
assignee: nobody → Kyle Huckins (khuckins)
Bill Erickson (berick) on 2019-04-04
Changed in evergreen:
assignee: Kyle Huckins (khuckins) → Bill Erickson (berick)
status: New → In Progress
Bill Erickson (berick) wrote :

My branch noted above has additions from Kyle with my sign-offs. I also pushed another commit to tidy some of the installer bits/docs a bit more.

Note for now, the Windows installer documentation only has the from-Linux install steps in entirety since 1) we only have a Linux version of the new dependency fetcher and 2) I'm assuming for now that's the primary build environment for the Windows installer.

I have tested the new build on a Windows machine which does not have Java installed. It worked as expected and it's all very tidy.

As a general heads up, I was not able to find an appropriately licensed version of the Windows JRE by itself. Only the full JDK build for Windows is available from OpenJDK. (Ditto https://aws.amazon.com/corretto/). This means the Hatch installer contains the full JDK (which is a superset of the JRE). This puts the installer at ~225M in size.

I will upload a sample build to this bug shortly for further testing.

Bill Erickson (berick) wrote :

New installer built with version 0.3.0. Can be downloaded here:

https://evergreen-ils.org/downloads/Hatch-Installer-0.3.0.exe

FWIW, this one was built on Windows via the Linux subsystem. Works fine.

Additional commits pushed for more deps and docs cleanup and a separate commit to bump the Hatch version numbers from 0.2.0 to 0.3.0.

tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.3.1
assignee: Bill Erickson (berick) → nobody
status: In Progress → Confirmed
Christopher Burton (cburton) wrote :

I have used this to circumvent the ERROR causing it to not even try printing the labels but I get several errors and the print fails. Works fine in the Printer Settings tester but not on the label printing page.

I presume more needs to be done for this?
It tries now but fails with the following console errors

core.bundle.js:1 No server setting type exists for cat.printlabels.last_settings, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template_context.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for cat.printlabels.last_settings, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label_cn, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label_cn, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for cat.printlabels.last_settings, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template_context.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template_context.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.last_printed
(anonymous) @ core.bundle.js:1

Just wanted to add this if it is of any use

Bill Erickson (berick) wrote :

Thanks, Christopher. The settings do need to be created -- some as workstation settings, some should be stored locally. I propose we open a separate LP for that. In my case, I was still able to print to a Dymo 330, regardless of the issues with the settings.

* I set the margins to HARDWARE_MINIMUM
* I set the correct paper type.
* When saving a spine label template, I had to save, close the tab, reopen the spine label print page and reapply the template before it would apply the desired changes.
* In my tests, I only printed the call number (no pocket labels) just to save paper -- the font would have to be tiny to fit both on the return address labels I was testing.

Related, I am also able to use the "Print" link for patron address printing. All I had to do there was modify the style in the patron_address template to fit all the text on the label:

<div style="font-size:.7em;">
....
</div>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers