Your error relates to the Java version, not the Guava version, so we can
reproduce the symptoms on the master branch. Compare the following
commands (only source versions differ):
mvn clean install -Dmaven.compile.source=1.7 -Dmaven.compile.target=1.8
-Danimal.sniffer.skip=true -Dmodernizer.skip -pl
project,core,:openstack-keystone
mvn clean install -Dmaven.compile.source=1.8 -Dmaven.compile.target=1.8
-Danimal.sniffer.skip=true -Dmodernizer.skip -pl
project,core,:openstack-keystone
The former succeeds but the latter fails with:
testListTenants(org.jclouds.openstack.keystone.v2_0.features.ServiceApiExpectTest)
Time elapsed: 0.031 sec <<< FAILURE!
java.lang.IllegalStateException: BindAuthToJsonPayload needs parameters
at
org.jclouds.openstack.keystone.v2_0.binders.BindAuthToJsonPayload.bindToRequest(BindAuthToJsonPayload.java:47)
at
org.jclouds.rest.binders.BindToJsonPayload.bindToRequest(BindToJsonPayload.java:43)
at
org.jclouds.openstack.keystone.v2_0.binders.BindAuthToJsonPayload.bindToRequest(BindAuthToJsonPayload.java:72)
at
org.jclouds.rest.internal.RestAnnotationProcessor.apply(RestAnnotationProcessor.java:352)
It appears that BindAuthToJsonPayload.bindToRequest(R request, Object
toBind) incorrectly overloads the superclass. Removing this overload
and fixing a few other call sites allows tests to pass. Perhaps JDK 8
overload resolution differs from earlier versions? I found this
reference:
https://stackoverflow.com/questions/30521974/why-does-the-java-8-generic-type-inference-pick-this-overload
I also created a pull request:
https://github.com/jclouds/jclouds/pull/1137
On Tue, Sep 05, 2017 at 04:20:19PM +0200, Ignasi Barrera 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/
--
Andrew Gaul
http://gaul.org/
