You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by "William L. Thomson Jr." <wl...@o-sinc.com> on 2018/02/20 19:25:28 UTC
Moving past Guava 20
Per request posting here to start a discussion on moving past Guava 20.
Please refer to the following.
https://issues.apache.org/jira/browse/JCLOUDS-1333
https://github.com/jclouds/jclouds/pull/1180
TL;DR; The issues raised in PR 1180 are summarized as follows;
- There are to many issues with trying to use Guava 21, skip
that version. (see PR for issues)
- To go to Guava 22+, requires moving to 1.8, as those jars
are built for newer Java. I do not believe available for
older.
-There are API changes in 22+, getHostText replaced with
getHost. Making it difficult to support older and newer Guava.
Which means for JClouds to move forward with Guava, likely have to drop
support for 1.7. That is mostly what needs to be discussed.
Can JClouds drop 1.7, and move forward to 1.8+ only?
May need to split code base and have a legacy version, and current.
Like 2.0.x supports 1.7, and 2.1.x supports 1.8+.
I feel there is no road forward for PR 1180, and will likely close as
such. I can open a new PR with changes for Guava 22+. Which are
considerably less than changes for 21. Which will cause issues with
Guava 22+. Thus skipping Guava 21 entirely.
FYI I have JClouds using Guava 24, and both built under Java 9, and
soon Java 10. The changes are not much, and seems fine. But does drop
legacy support.
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/jclouds-core/jclouds-core-9999.ebuild#L34
Me personally I am past 1.8. But seems a fair amount are still running
that version. It is still supported by most vendors.
http://www.oracle.com/technetwork/java/eol-135779.html
https://developer.ibm.com/javasdk/support/lifecycle/
https://access.redhat.com/articles/1299013
--
William L. Thomson Jr.
Re: Moving past Guava 20
Posted by "William L. Thomson Jr." <wl...@o-sinc.com>.
On Tue, 20 Feb 2018 23:47:36 -0800
Andrew Gaul <ga...@apache.org> wrote:
> Looking at the JCLOUDS-1xxx issues (September 2015 to present), our
> users reported 8 JDK 7 issues and 8 JDK 8 issues. You can repeat this
> analysis via:
That does not really help favor one over the other. Really seems like a
call will have to be made. Continue supporting both, or stop supporting
1.7, or just bug fix etc. Probably need to look into what the actual
issues are with 1.7.
Seems like something all projects are faced with, and having supported
1.7 for this long. I think you all have been generous enough. I would
just move to 1.8, and if anyone needs 1.7 support still. Have them help
with maintaining a version for such.
Going forward I would assume less to need 1.7, and those still on 1.7
eventually will move past. JClouds usage on 1.7 should be declining vs
increasing.
--
William L. Thomson Jr.
Re: Moving past Guava 20
Posted by Andrew Gaul <ga...@apache.org>.
Looking at the JCLOUDS-1xxx issues (September 2015 to present), our
users reported 8 JDK 7 issues and 8 JDK 8 issues. You can repeat this
analysis via:
for i in `seq 1400`; do echo $i; wget https://issues.apache.org/jira/si/jira.issueviews:issue-xml/JCLOUDS-$i/JCLOUDS-$i.xml; done
grep -A1 '<environment>' JCLOUDS-* | grep -i -e jdk -e java | tr '\r' '\n'
On Tue, Feb 20, 2018 at 11:33:52PM -0800, Andrew Gaul wrote:
> To establish the current state, I believe that jclouds works with Java
> 6-8 and 9 with --add-modules java.xml.bind and Guava 18-23, although I
> will defer to you about the lack of 22+ support. Guava has proven to be
> a painful dependency and one we should minimize going forward, even with
> the stronger compatibility pledges from the Guava team.
>
> While supporting users with antique Java and Guava version has noble
> intentions, I do not believe we have the development resources to
> support all things for all people. Personally I prefer to support only
> Java 8 and newer and Guava 21 and onwards, the first Guava to support
> Java 8. However, several contributors championed more backwards
> compatibility in the following mailing list threads:
>
> https://lists.apache.org/thread.html/1089e75e6be122024a3c1a45fdfd8c4c6545ce8df319a46c83831684@1401303438@%3Cuser.jclouds.apache.org%3E
> https://lists.apache.org/thread.html/b8f2d9f55a3f8ebc07068dbe85cbef9dff0470b21ddbc89fa78601ac@1414426875@%3Cdev.jclouds.apache.org%3E
> https://lists.apache.org/thread.html/2653bad70cbad009b54c612f02b4c6a09fd02dcd111c7319b9ed3b26@%3Cdev.jclouds.apache.org%3E
>
> I still loathe to touch the third rail of dependency versioning but the
> pain of old software exceeds my interests and I believe deters users
> with newer software and contributors. If someone wants to use or
> support the older users please speak up and volunteer your time for this
> Sisyphean task.
>
> [As a small suggestion, we can easily use reflection to call either
> getHostText or getHost with older Guava.]
>
> On Tue, Feb 20, 2018 at 02:25:28PM -0500, William L. Thomson Jr. wrote:
> > Per request posting here to start a discussion on moving past Guava 20.
> > Please refer to the following.
> >
> > https://issues.apache.org/jira/browse/JCLOUDS-1333
> > https://github.com/jclouds/jclouds/pull/1180
> >
> > TL;DR; The issues raised in PR 1180 are summarized as follows;
> >
> > - There are to many issues with trying to use Guava 21, skip
> > that version. (see PR for issues)
> > - To go to Guava 22+, requires moving to 1.8, as those jars
> > are built for newer Java. I do not believe available for
> > older.
> > -There are API changes in 22+, getHostText replaced with
> > getHost. Making it difficult to support older and newer Guava.
> >
> > Which means for JClouds to move forward with Guava, likely have to drop
> > support for 1.7. That is mostly what needs to be discussed.
> >
> > Can JClouds drop 1.7, and move forward to 1.8+ only?
> >
> > May need to split code base and have a legacy version, and current.
> > Like 2.0.x supports 1.7, and 2.1.x supports 1.8+.
> >
> > I feel there is no road forward for PR 1180, and will likely close as
> > such. I can open a new PR with changes for Guava 22+. Which are
> > considerably less than changes for 21. Which will cause issues with
> > Guava 22+. Thus skipping Guava 21 entirely.
> >
> > FYI I have JClouds using Guava 24, and both built under Java 9, and
> > soon Java 10. The changes are not much, and seems fine. But does drop
> > legacy support.
> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/jclouds-core/jclouds-core-9999.ebuild#L34
> >
> > Me personally I am past 1.8. But seems a fair amount are still running
> > that version. It is still supported by most vendors.
> >
> > http://www.oracle.com/technetwork/java/eol-135779.html
> > https://developer.ibm.com/javasdk/support/lifecycle/
> > https://access.redhat.com/articles/1299013
> >
> > --
> > William L. Thomson Jr.
>
>
>
> --
> Andrew Gaul
> http://gaul.org/
--
Andrew Gaul
http://gaul.org/
Re: Moving past Guava 20
Posted by "William L. Thomson Jr." <wl...@o-sinc.com>.
On Tue, 20 Feb 2018 23:33:52 -0800
Andrew Gaul <ga...@apache.org> wrote:
> To establish the current state, I believe that jclouds works with Java
> 6-8 and 9 with --add-modules java.xml.bind
For the record I do not believe I had to modify JClouds at all for 9.
It is more dependencies causing issues for JClouds.
> and Guava 18-23, although I will defer to you about the lack of 22+
> support.
I have issues with Guava 20, and 21.
mvn clean install -Dguava.version=20.0 -pl :jclouds-core -am
-Dmaven.compile.source=1.8 -Dmaven.compile.target=1.8
-Dmaven.test.skip=true
1:check (default) on project jclouds-core: Execution default of goal
org.codehaus.mojo:animal-sniffer-maven-plugin:1.11:check failed.:
IllegalArgumentException -> [Help 1]
Guava 21, I get the output in initial comment
https://issues.apache.org/jira/browse/JCLOUDS-1333
If I drop source/target 1.8 with Guava 21 I get output like in this
comment, 2nd code block
https://github.com/jclouds/jclouds/pull/1180#issuecomment-366168595
Same for Guava 22+, but there would be further failures with
getHostText change to getHost.
Guava 23
/projects/jclouds/core/src/main/java/org/jclouds/rest/internal/InvokeHttpMethod.java:128:
error: method callWithTimeout in interface TimeLimiter cannot be
applied to given types; .callWithTimeout(new
InvokeAndTransform(commandName, command), limitNanos, NANOSECONDS,
true); ^ required: Callable<T>,long,TimeUnit found:
InvokeHttpMethod.InvokeAndTransform,long,TimeUnit,boolean reason:
cannot infer type-variable(s) T (actual and formal argument lists
differ in length) where T is a type-variable:
T extends Object declared in method
<T>callWithTimeout(Callable<T>,long,TimeUnit)
> Guava has proven to
> be a painful dependency and one we should minimize going forward,
> even with the stronger compatibility pledges from the Guava team.
Yes that is where my gripes with JClouds come from, guice, gson, and
guava. I have worked around all for my needs. Guava does seem to
require more changes than guice and gson. Guice was already fixed per
past PR. Gson has OSGi issues/limitations, so that is a logical
limitation to moving forward.
Guava not sure, but does seem better 22+. Most anything that worked
with 22 works with 23 and 24. I only have a few things stuck on Guava
21. I had 20 just for JClouds but was able to remove that.
> While supporting users with antique Java and Guava version has noble
> intentions, I do not believe we have the development resources to
> support all things for all people. Personally I prefer to support
> only Java 8 and newer and Guava 21 and onwards, the first Guava to
> support Java 8.
I agree with your persona preference. I am a forward only type with
Java. I hate using source/target/release to target older... I try to
avoid such at all costs.
Though I am not sure Guava 21 is worth it, thus I would go to 22 and
1.8+. From there I think you are good to go. No more issues with Guava
and/or JDK. Guava 21 seems to be a can of worms, between JClouds code
and JDK changes in 1.8+. Per PR madness, hundreds of files need to be
addressed. That will cause breakage/issue under Guava 22+.
You cannot add override where needed for Guava 21, it fails if you add
them. Come Guava 22+, Overrides will be needed, if not overrided code
removed as it is not needed with 22+. That is a flip flop mess....
All the public boolean test()
https://patch-diff.githubusercontent.com/raw/jclouds/jclouds/pull/1180.diff
That is already in Guava, but uses default which causes issues.
https://github.com/google/guava/blob/f58203fbc4ba0597fdbc7cfebe7ff2c5ce6ec1d4/guava/src/com/google/common/base/Predicate.java
>However, several contributors championed more
> backwards compatibility in the following mailing list threads:
Maybe they can maintain a back ported legacy branch for their interest
and needs.
> I still loathe to touch the third rail of dependency versioning but
> the pain of old software exceeds my interests and I believe deters
> users with newer software and contributors. If someone wants to use
> or support the older users please speak up and volunteer your time
> for this Sisyphean task.
You are correct on newer contributions. For me to contribute I would
only be interested in working with the latest dependencies etc. It
would be a pain otherwise. Have to develop outside my env. Still may
look to do something for Linode, which I use. Also Vultr would be nice.
In my ENV I have all deps up to latest versions, and ideally only 1
version of each dep, the latest. In addition to the latest compiler,
makes it a current ENV. Which sucks for any legacy coding... Huge pain
to go back and support older. Less a version/slot here and there.
Many things are stuck on older. Zookeeper is stuck on an ancient Netty
from JBoss.org. I tried to update, but not familiar with Netty. No one
else has finished what I started. Which is like 80-90% of the way.
https://issues.apache.org/jira/browse/ZOOKEEPER-2399
> [As a small suggestion, we can easily use reflection to call either
> getHostText or getHost with older Guava.]
That is minor. Not sure reflection can help with the Override Predicate
test method situation. That is the real can of worms with 21. 22+ no
longer an issue. That is what caused me to give up on 21. I am not sure
how you can cleanly code around that issue. Short of some wrapper or
changing Guava.
--
William L. Thomson Jr.
Re: Moving past Guava 20
Posted by Andrew Gaul <ga...@apache.org>.
To establish the current state, I believe that jclouds works with Java
6-8 and 9 with --add-modules java.xml.bind and Guava 18-23, although I
will defer to you about the lack of 22+ support. Guava has proven to be
a painful dependency and one we should minimize going forward, even with
the stronger compatibility pledges from the Guava team.
While supporting users with antique Java and Guava version has noble
intentions, I do not believe we have the development resources to
support all things for all people. Personally I prefer to support only
Java 8 and newer and Guava 21 and onwards, the first Guava to support
Java 8. However, several contributors championed more backwards
compatibility in the following mailing list threads:
https://lists.apache.org/thread.html/1089e75e6be122024a3c1a45fdfd8c4c6545ce8df319a46c83831684@1401303438@%3Cuser.jclouds.apache.org%3E
https://lists.apache.org/thread.html/b8f2d9f55a3f8ebc07068dbe85cbef9dff0470b21ddbc89fa78601ac@1414426875@%3Cdev.jclouds.apache.org%3E
https://lists.apache.org/thread.html/2653bad70cbad009b54c612f02b4c6a09fd02dcd111c7319b9ed3b26@%3Cdev.jclouds.apache.org%3E
I still loathe to touch the third rail of dependency versioning but the
pain of old software exceeds my interests and I believe deters users
with newer software and contributors. If someone wants to use or
support the older users please speak up and volunteer your time for this
Sisyphean task.
[As a small suggestion, we can easily use reflection to call either
getHostText or getHost with older Guava.]
On Tue, Feb 20, 2018 at 02:25:28PM -0500, William L. Thomson Jr. wrote:
> Per request posting here to start a discussion on moving past Guava 20.
> Please refer to the following.
>
> https://issues.apache.org/jira/browse/JCLOUDS-1333
> https://github.com/jclouds/jclouds/pull/1180
>
> TL;DR; The issues raised in PR 1180 are summarized as follows;
>
> - There are to many issues with trying to use Guava 21, skip
> that version. (see PR for issues)
> - To go to Guava 22+, requires moving to 1.8, as those jars
> are built for newer Java. I do not believe available for
> older.
> -There are API changes in 22+, getHostText replaced with
> getHost. Making it difficult to support older and newer Guava.
>
> Which means for JClouds to move forward with Guava, likely have to drop
> support for 1.7. That is mostly what needs to be discussed.
>
> Can JClouds drop 1.7, and move forward to 1.8+ only?
>
> May need to split code base and have a legacy version, and current.
> Like 2.0.x supports 1.7, and 2.1.x supports 1.8+.
>
> I feel there is no road forward for PR 1180, and will likely close as
> such. I can open a new PR with changes for Guava 22+. Which are
> considerably less than changes for 21. Which will cause issues with
> Guava 22+. Thus skipping Guava 21 entirely.
>
> FYI I have JClouds using Guava 24, and both built under Java 9, and
> soon Java 10. The changes are not much, and seems fine. But does drop
> legacy support.
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/jclouds-core/jclouds-core-9999.ebuild#L34
>
> Me personally I am past 1.8. But seems a fair amount are still running
> that version. It is still supported by most vendors.
>
> http://www.oracle.com/technetwork/java/eol-135779.html
> https://developer.ibm.com/javasdk/support/lifecycle/
> https://access.redhat.com/articles/1299013
>
> --
> William L. Thomson Jr.
--
Andrew Gaul
http://gaul.org/