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 <[email protected]> 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/
