On Tue, 20 Feb 2018 23:33:52 -0800 Andrew Gaul <g...@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.
