[DISCUSS] Java Version 1.6 Support

[Nick Couchman <vn...@apache.org>]

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?

-Nick

Re: [DISCUSS] Java Version 1.6 Support

[Nick Couchman <vn...@apache.org>]

>
> 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

Re: [DISCUSS] Java Version 1.6 Support

[Mike Jumper <mi...@guac-dev.org>]

On Wed, Dec 13, 2017 at 8:37 AM, Nick Couchman <vn...@apache.org> wrote:

> On Wed, Dec 13, 2017 at 7:25 AM, carl harris <ce...@gmail.com>
> 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

Re: [DISCUSS] Java Version 1.6 Support

[Nick Couchman <vn...@apache.org>]

On Wed, Dec 13, 2017 at 7:25 AM, carl harris <ce...@gmail.com> 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

Re: [DISCUSS] Java Version 1.6 Support

[carl harris <ce...@gmail.com>]

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 <mi...@guac-dev.org> wrote:
> 
> On Tue, Oct 31, 2017 at 6:18 AM, Nick Couchman <vn...@apache.org> 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

Re: [DISCUSS] Java Version 1.6 Support

[Mike Jumper <mi...@guac-dev.org>]

On Tue, Oct 31, 2017 at 6:18 AM, Nick Couchman <vn...@apache.org> 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