On Wed, Dec 13, 2017 at 8:37 AM, Nick Couchman <[email protected]> wrote:
> On Wed, Dec 13, 2017 at 7:25 AM, carl harris <[email protected]> > wrote: > ... > > 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. > > > > Yeah, I've been on the sys admin side of things where I've been told that a > certain, antiquated version of Java is required for a certain application. > I may even know of an application or two that's still around using Java 1.3 > :-/. It does highlight, though, that certain applications tend to rely on > past versions of Java for some reason or another. > > Well ... in our case, it's not that we're requiring an older version of Java, but rather that we maintain compatibility with an older version of Java. I'm not really sure what would be the best test for determining when it's reasonable to drop support for a particular release of Java, though I do see that Tomcat 7 supports Java 6 and later (though it requires Java 7 for WebSocket). That said, newer versions of Tomcat do indeed require at least Java 7, with the latest releases requiring Java 8. It could be argued that we should follow suit. > > > > 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. > > > > I'm speculating, and Mike can definitely comment more, but I'd say it's > possible that because Guacamole is an API and does offer the library > aspect, perhaps that's the motivation for not jumping JDK versions quite so > readily and quickly as if it were just an application?? Again, speculation > - Mike can set that record straight. > > The fact that Guacamole offers a low-level API is a significant concern. To that end, I'd revise my earlier "let's move everything to 1.7" suggestion to exclude the lowest-level Java API, guacamole-common. The extension API, which is completely tied to the web application, is a bit safer with respect to requiring a newer JRE / JDK. > > > > > 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. > > > > I agree, with proof - in at least two specific instances I've run into > issues that did not work in Java 1.6: > - When adding the ClearPass functionality to the CAS authentication > extension, the process of reading in the key file would have been made > substantially easier by functionality available in Java 1.7 and later that > is not present in 1.6. I was able to work around the issue with code that > is reasonably well-accepted when using Java 1.6, but the number of lines of > code would have been reduced with the later code. Not a huge deal, just a > minor inconvenience. > - When converting the LDAP authentication extension from the antiquated > Novell JLDAP library to the newer Apache library, Java 1.7 is listed as a > requirement for the Apache API. Note that I did not test to see what > happens if you do not upgrade compatibility to 1.7 - I assume that it would > probably compile fine, since the Apache APIis an external, pre-compiled > library, and that you would just encounter runtime errors if you tried to > run it with a version of Java older than 1.7. > > Similar to Tomcat, having particular features of Guacamole require newer versions of Java is less of a concern to me than requiring newer versions of Java across the whole of guacamole-client. >... > > 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? > > > The only JRE that would apply to a Guacamole deployment is the JRE which runs the servlet container. > 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. > I like this, however since we currently only maintain support for one version at a time, this might not solve things entirely. There would still be the case where a new release of Guacamole containing a critical update is created, and downstream users are forced to update their JRE in order to make use of the update. - Mike
