On Wed, Dec 13, 2017 at 7:25 AM, carl harris <[email protected]> wrote:
> 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. > Your input is definitely welcome. From my perspective, my reasons for initiating this discussion were because I've run into a couple of instances recently when modifying extensions where 1.6 is not supported. Since 1.6 is way out of support, it seems relatively safe to me to move on to a later version - 1.7 would suffice for the changes I wanted to make, but I certainly think it is worth exploring reasons to move or not to move to 1.8. I'm new enough to the project that I don't have the historical context to comment on what the reason for not jumping up to later releases would be - Mike would have to comment on that and provide the reasons. He did point out that, from his perspective, 1.7 is still in pretty broad use, even if it is not being updated, as you noted below. > > 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. > 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. > > 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. > > 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. > > 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? > You're probably correct, although my first use case above was a compile-time issue, since the classes added in 1.7 that I was trying to use to read in the key file only exist in the Java 1.7 code, there were, I believe, errors during compile time as it checked the compatibility of the code against the version specified, 1.6. In the second case, while I didn't try it, I believe it would have compiled and run fine in my environment since I'm running Java 1.8. > > 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. > > This seems sane to me, but it seems that we would also need to discuss roadmap and plan versions in a little bit more of a forward-looking fashion. For example, the issues I mentioned above - the LDAP library change is something that might be "major enough" to warrant bumping a major version in Guacamole, but adding the ClearPass feature to CAS does not necessarily seem like something that warrants a major version bump (I was able to work around the requirement in that case, it was just not quite as easy). Again, I'm not disagreeing, just pointing out that I believe it is going to require some additional planning of major vs. minor releases. -Nick
