> > 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. >
...without forgetting other potential servlet containers that we might want to maintain support for, like JBoss, Websphere, Jetty... :-) > > > > > > > > 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. > > 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. > So, the only concern I have in doing this is the potential to cause confusion. I will fully admit that this probably is a very minor concern, since most people will just run pre-built Guacamole JARs with the latest Tomcat and JRE, but there's definitely the potential for us to create a situation where it's hard to determine exactly the minimum version of Java required, because the API only requires 1.6, but the base client requires 1.7, but one of the three extensions in use requires 1.8. Again, probably not a huge deal and may be outweighed by the other concerns enumerated in this thread, but it just seems like we could end up making this unnecessarily complicated - for ourselves as project maintainers, if nothing else. -Nick
