Here is my WIP branch for this: https://github.com/nacx/jclouds/commits/1333-guava21
On 5 September 2017 at 16:20, Ignasi Barrera <n...@apache.org> wrote: > Great job Andrew, and thanks for leading this! > > I've started to fix the Java8 with Guava 21+ build, and most of the > errors are type resolution errors for generics when using the Guava > helpers. I've changed all those (by explicitly declaring variables, as > we did here [1]) but then got into a test failure in an OpenStack > Keystone HTTP binder. > > The code enters this method [2] when it should be entering this one [3]. > > It definitely reveals that there is something that's completely wrong > in the type resolution, and that is also affecting code at runtime. I > haven't been able to figure out yet what is going on nor able to > refactor the binder classes to bypass the issue, but I'm not sure if > all these changes are actually needed or just a pointer that there is > something wrong elsewhere that should be properly configured/fixed. > > More eyes help on this would be highly appreciated! > > > I. > > > BTW, the build can be run as follows, to reproduce the issues: > mvn clean install -Dguava.version=21.0 -Dmaven.compile.source=1.8 > -Dmaven.compile.target=1.8 -Danimal.sniffer.skip=true > -Dmodernizer.skip > > > [1] https://github.com/jclouds/jclouds/pull/1036#issuecomment-319904820 > [2] > https://github.com/jclouds/jclouds/blob/master/apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/binders/BindAuthToJsonPayload.java#L47 > [3] > https://github.com/jclouds/jclouds/blob/master/apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/binders/BindAuthToJsonPayload.java#L59 > > On 22 August 2017 at 00:11, Andrew Gaul <g...@apache.org> wrote: >> This issue finally irritated me enough to go with option 1 and hack >> around with sed: >> >> https://github.com/jclouds/jclouds/pull/1131 >> >> This allowed me to use Guava 23 with S3Proxy. Testing jclouds itself >> with Guava 21+ revealed breakage with Java 8 but this does not impact >> our users. >> >> I discovered google-java-format[1] which helped with some of the import >> changes. This has similarities to gofmt although it uses a >> substantially different coding style than ours. >> >> [1] https://github.com/google/google-java-format >> >> On Mon, Jul 03, 2017 at 06:06:06PM -0700, Andrew Gaul wrote: >>> Three months have passed so I guess we chose option 0. While this issue >>> concerns me and prefer options 1 or 2, I do not plan to work on this and >>> encourage someone to step forward with a pull request or suggest another >>> approach. >>> >>> On Thu, Mar 30, 2017 at 10:11:56PM -0700, Andrew Gaul wrote: >>> > I want to raise the profile of JCLOUDS-1225[1], Guava 21 compatibility, >>> > which has troubled several users recently. jclouds uses Guava 16 and >>> > has compatibility with Guava 16-20. Guava 21 API changes make it >>> > incompatible with jclouds. We have several plausible solutions: >>> > >>> > 0) Ignore the issue >>> > 1) Move to Guava 18 and have compatibility with Guava 18-21 >>> > 2) Use reflection or other workarounds to conditionally call newer >>> > Guava APIs >>> > 3) Provide some kind of shaded solution to avoid application >>> > incompatibilities >>> > >>> > I loathe to touch the third rail of dependency versioning given the >>> > history of strong opinions and a reversion which addressed this very >>> > issue some years back. How can we move forward here? 0 and 1 cause >>> > user issues while 2 and 3 pollute our code with hacks. >>> > >>> > [1] https://issues.apache.org/jira/browse/JCLOUDS-1225 >>> > >>> > -- >>> > Andrew Gaul >>> > http://gaul.org/ >>> >>> -- >>> Andrew Gaul >>> http://gaul.org/ >> >> -- >> Andrew Gaul >> http://gaul.org/
