Switch to Java 8

[ctrueden]

We need to update ImageJ to be based on Java 8 instead of Java 6.

Why update

• Recent versions of Java 8 support Let's Encrypt SSL certificates; Java 6 does not. Hence, the ImageJ Updater needs Java 8 to offer secure (HTTPS) updates.
• Java 6 is considered unsafe from a security perspective. This is less of a concern for desktop applications than web ones, but still potentially a concern: many IT departments no longer allow Java 6 to be installed on their machines.
• Java 6 has crash bugs that will never be fixed. These bugs impact Fiji's Stitching plugins, causing hours-long computations to terminate unexpectedly with no recourse. These bugs are fixed in Java 7 and 8.
• Java 7 has critical performance problems on OS X that will never be fixed. These problems cause ImageJ to paint images incredibly slowly. This painting issue is fixed in Java 8.
• Java 6 and 7 have reached "end of life" status and are no longer supported by Oracle. This means there will be no more publicly available bug-fixes for these versions of Java.
• Support for Java 6 on Apple platforms is deprecated, and will be discontinued in a future version of OS X.
• We cannot create an OS X version of ImageJ that bundles Java 6, but we can do so for Java 8. Doing this will allow us to make ImageJ available from the Mac App Store.
• Bio-Formats 5.2.x will require Java 7.
• Jython 1.7 requires Java 7.
• Java 3D 1.6 requires Java 7.
• ClearVolume requires Java 7.
• Mines JTK (a dependency of some ImgLib2 and Fiji components) recently changed to the Apache 2 license, making it compatible with the GPLv3—good news for Fiji. But (you guessed it) Mines JTK now requires Java 7.
• JRuby depends on headius invokebinder, which requires Java 7. (In practice JRuby seems to work with Java 6, but it is still version leakage.)
• Java 8 includes JavaFX, a modern UI framework which will be a great target for a next-generation ImageJ application.
• Java 8's JavaFX library also provides a native launcher which could free us from maintaining the current ImageJ Launcher, which is complex and error prone.
• Java 8 has many enhancements for programmers which make the design and implementation of functionality much more efficient, elegant and maintainable. The sooner we switch, the more we minimize our future technical debt.
• The Travis CI system used to automate ImageJ component builds no longer supports building with Java 6; the environment must be Java 7 or Java 8. So validating that Java 6 will still actually work becomes more difficult.

  What needs to happen

• [x] Switch to Java 3D 1.6, which supports Java 7 and 8. (imagej/imagej#120)
• [x] Make Java scripting work in Java 7 and 8. (imagej/imagej#105; fiji/fiji#119)
• [ ] Switch to JavaFX native launcher. (imagej/imagej-launcher#33)
• [ ] Fix all showstopper Java-8-related bugs.

  See also

• 2015-06-15 - Major updates in the works
• Issues with deployment tag

[ctrueden]

We switched to Java 8 maybe a decade ago now. :wink: I resisted closing this issue because we never managed to get rid of the add-on update site called Java-8... but that's life.