I'd be very interested to discuss what we think are the forces that influence the decision about what JDK version to use for Guacamole. I'm not advocating for any particular version of Java here, and I'll apologize in advance if my questions or the call for discussion are unwelcome. Also, while I didn't start out with this intent, the following is a longer read than I would prefer. Just trying to stimulate thought and constructive debate and that's sometimes a tough bill in the context of a mailing list.
Neither Java 1.6 nor Java 1.7 are supported even for critical updates. Oracle announced in October their plans to a much more aggressive (twice annual) release schedule for Java, starting in March 2018. It seems like a good time to think about what can be done to stay reasonably current without creating problems for those who develop, build, install, and/or run Guacamole. I've worked on lots of library projects, producing code that is intended to be incorporated on the class path of someone else's application. In that context, supporting a pretty long tail of Java versions is generally a necessary evil. Is Guacamole commonly used in this manner -- as a library of Java classes used inside someone else's Java application? If so, the decision about JDK version has to be driven by the choice of JDK for the projects in which it is used. If Guacamole is most commonly used and integrated as an application instead of as a Java library, then it would seem that there are three points in time at which the JDK choice is relevant, involving three different roles. 1. At development time, when we write code for Guacamole as part of the project itself or as part of third-party extensions. 2. At build time, when someone closer to the operations end of the spectrum builds Guacamole from source (as opposed to downloading and running a pre-built distribution). 3. At deployment time, when someone on the operations end of the spectrum makes a compatible JRE available to run the finished product. Without proof, I'll offer that developers are generally unhappy to be blocked from using new features of the language or JDK when writing code, and thus would tend to act as a force influencing the use of the latest JDK. Also without proof, I'll offer that the choice of JDK is rarely a significant obstacle at build time. People who are responsible for building software generally have to support a variety of different versions of build tooling and have workable mechanisms to cope with that. This seems to leave deployment time as the time when the JDK choice is most significant. Am I missing something here? Do we have any useful evidence that would help us understand the ways in which Guacamole is deployed? For example, is it common for Guacamole to share a JRE with some other application (other than the servlet container in which it runs) on the same host? Would we consider stating a JRE version requirement for each major release of Guacamole? This would create a less open-ended timeline for use of some particular JDK version, and would allow the team to make the requirement known well before the release itself. It seems like this approach is fairly common in open source application projects. carl > On Dec 9, 2017, at 7:36 PM, Mike Jumper <[email protected]> wrote: > > On Tue, Oct 31, 2017 at 6:18 AM, Nick Couchman <[email protected]> wrote: > >> This has come up in a couple of PRs, so I wanted to throw this out for >> discussion. Currently most of the Guacamole client code is targeted at >> Java 1.6 compatibility (via entries in the pom.xml files). There have been >> a couple of instances where that was a minor inconvenience, though not all >> that problematic. However, I just did a PR for migrating the LDAP >> authentication extension from the legacy Novell LDAP API over to Apache's >> Directory LDAP API, and that (apparently) requires Java 1.7 or later. >> >> For the LDAP extension it's easy to just require that to be at 1.7 and >> allow the rest to be at 1.6, but the question becomes: is there any reason >> *not* to bump the requirement/target/compatibility for Java to 1.7 or even >> 1.8 across the board? The last publicly-available 1.6 version was in 2015 >> (U91), with 1.8 starting in 2014 and 1.9 starting this year. Seems like >> it's probably pretty safe to move beyond 1.6? >> >> Thoughts? >> >> > I would be happy to see everything bumped up to Java 7. > > I don't think we can safely bump all the way to Java 8 across the board, as > I believe it's still relatively widely used and supported, but I'd be > interested to hear what others think here. > > - Mike
