Java: Use javapackager to provide a standalone Windows and Mac viewer

[dcommander]

This would bundle a JRE in the Windows and Mac Java viewers, so they could be used even if a JRE is not installed. The downside of this (refer to https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html#A1307236) is that the viewers would not automatically get security updates. In our case, however, those mainly apply to the built-in encryption features, and we would have the same issues if we implemented those features in our native viewer, per #8 and #6. All Linux distros these days ship with OpenJDK or make it very easy to install it, so bundling a JRE is unnecessary on that platform. This is mainly for those who want to use our Mac viewer, or those who want to use the encryption features in our Java viewer on Windows, without installing Java. The Windows native viewer is very popular, and there are no immediate plans to get rid of it, but having a standalone Java viewer on that platform would at least allow us to focus on the strengths of each viewer instead of trying to make both viewers be all things to all people.

[dcommander]

NOTE regarding licensing: It is my understanding that bundling a JRE will not violate the terms of the GPL, since the TurboVNC Viewer does not specifically depend on the embedded JRE, but I need to investigate whether there are any hidden legal "gotchas" in terms of redistributing an embedded Oracle JRE. Ideally, the viewer would use the embedded JRE by default, but there would be a way to override that and make it use the installed one, if a user so chooses.

[dcommander]

Ugh. I tried this out, and it causes the distribution packages to exceed 60 MB in size. For now, I'm going to say "no thanks." That downside, combined with the downside of having to provide security updates ourselves, is just too much to justify. It isn't much more of a burden to go to java.com and download/install their 60 MB package, which provides automatic security updates, as opposed to downloading/installing a 60 MB package from our site.

[dcommander]

Revisit with Java 9, since it now has the ability to embed only the necessary JRE components in an application. If that enables distributing a more reasonably-sized bundle, then I'm willing to do that for TurboVNC 2.2. The Windows native viewer will definitely be in TurboVNC 2.2, but in the long term (3.0), it would be nice to transition to a unified viewer code base. Currently, this is where we stand with respect to viewer features:

Only in Windows native viewer:

• Wacom support for Windows clients
  • was not able to figure out how to implement in the Java viewer, because on Windows, the Wacom drivers deliver events asynchronously from regular mouse events
• Per-connection settings (would like to implement in the Java viewer for TurboVNC 2.2)
• Three-button mouse support (see Viewer: 3-button mouse emulation #5)
• Bump scrolling

Only in Java viewer

• Built-in SSH support (see Improve SSH tunneling support in the Windows TurboVNC Viewer #6)
• VeNCrypt/TLS encryption support (see Implement VeNCrypt in Windows Viewer #8)
• The ability to reverse the scroll wheel direction
• Zero-install capability
• rfbTLS support (for Vino servers)
• UltraVNC Repeater support

Furthermore, multi-threading (see #60) is likely easier to implement in Java, since our Windows viewer is still based on bare-metal ("Petzold") Windows GUI code.

[dcommander]

I was able to convert the TurboVNC Viewer JAR for use with jlink and produce a custom JRE by using the following command sequence (performed from the TurboVNC build directory):

make java
jdeps --generate-module-info java java/VncViewer.jar
javac --patch-module VncViewer=java/VncViewer.jar java/VncViewer/module-info.java
jar uf java/VncViewer.jar -C java/VncViewer module-info.class
jlink -p java/VncViewer.jar:$JAVA_HOME/jmods --add-modules VncViewer --limit-modules VncViewer --output jre --ignore-signing-information

NOTE: it took me a while to figure this out. The process is not well-documented.

The resulting JRE is 82 MB in size, which is still quite big. Given the disadvantages of this approach (specifically, that the TurboVNC Viewer would be "stuck" on whichever JRE we built it with, and users would not be able to get security updates or bug fixes for that JRE unless we released a new TurboVNC Viewer package), I was really hoping that there would be more of an advantage in terms of reduced disk footprint or build complexity. That doesn't seem to be the case, unfortunately. The only real advantage to the bundled JRE approach would be reduced deployment complexity (i.e. users would not have to install a JRE prior to installing/using the TurboVNC Viewer.) At the moment, that just doesn't seem compelling enough.

I will keep monitoring the progress of Java development. In the long term, they seem to be moving toward a bundled JRE approach or possibly even toward AOT compilation, so something like this may have to happen eventually. Right now, however, Java is in too much of a state of flux for me to feel comfortable spending any significant time on a project such as this.

[dcommander]

It seems that Oracle has taken the following steps in Java 11:

• Removing the javapackager tool
• Removing Java Web Start
• Removing the standalone JRE (you must now download and install the JDK in order to run Java applications.)

This has basically forced my hand on the issue, and it seems that the only reasonable path forward is to treat Java as a language rather than a platform and to embed a JRE into the TurboVNC Viewer application, at least on platforms for which OpenJDK isn't provided by the O/S. Now the question becomes how to do that without javapackager. :/ Thanks, Oracle.

[dcommander]

This has been implemented with the Mac TurboVNC Viewer:
https://s3.amazonaws.com/turbovnc-pr/dev/osx/index.html

[dcommander]

And the 64-bit Windows/Java TurboVNC Viewer:
https://ci.appveyor.com/project/dcommander/turbovnc/build/artifacts?branch=dev