Le dim. 21 mars 2021 à 08:13, Andrew Gaul <gaul@apache.org> a écrit :
On Thu, Mar 18, 2021 at 10:39:05AM +0100, Jean-Noėl Rouvignac (ForgeRock) wrote:
> I have started looking at ListenableFuture.
> TBH I don't know where to start! A lot of things are public, so I don't
> think I can change them straight from ListenableFuture to CompletableFuture?
> They are also often used in conjunction with ListeningExecutorService which
> makes the problem worse.

Ugh, I incorrectly believed that ListenableFuture inherited from
CompletableFuture but instead they both inherit from Future.  There does
not seem to be an easy path forward here.  In the past we have done some
heavyweight @Deprecate-and-change-the-interface changes but these are a
lot of work.  I would add that the only important ones to change are the
interfaces, not the implementation.  Thus something like

ListenableFuture<ExecResponse> BaseComputeService.submitScriptOnNode(String id, String runScript, RunScriptOptions options)

is problematic but

Set<? extends NodeMetadata> BaseComputeService.resumeNodesMatching(Predicate<? super NodeMetadata> filter)

is not.  In an ideal future Guava would be an implementation detail and
not part of the interface

I also found some ListenableFuture vs. CompletableFuture migration tips:

https://github.com/krka/java8-future-guide

Finally it might be worth looking through other projects which
struggling with Guava dependency issues, e.g.,
https://issues.apache.org/jira/browse/HADOOP-17098 .  jclouds is not
alone in its Guava over-dependency.

Oh! Excellent! Thanks for these pointers. I quickly looked for some but did not find any that was compelling.
 
> I have noticed a lot of usages of Guava functional interfaces. These could
> be replaced by JDK functional interfaces, but I have the same with public
> constructors / APIs. Plus I think I may have a problem with Guice if it
> uses reflection to instantiate the objects. I am only guessing this could
> be a problem without any proof yet.
> Doing that, I realized there was a lot of code which could be using lambdas
> instead of creating subclasses of guavas functional interfaces.
> I think this would be a step in the right direction because lambdas are not
> linked to the type they implement, so it becomes easier to switch from
> guava functional interfaces to Java functional interfaces. This is doable
> because jclouds is now using Java 8.
> How do you feel about the use of lambdas in jclouds?
>
> I also noticed a lot of generic type parameters can now be removed because
> type inference has improved a lot with Java 8.
> Would you be OK with PRs removing unnecessary generic type parameters?

-1 on cosmetic changes.  If you can cast these into an automated tool
like google-java-format or refaster we could discuss this (not an IDE
magically changing a bunch of things) but even then I view these as low
value tasks.  For example I hate 3-space indentation as much as everyone
else but the costs far outweigh the benefits.  Honestly I maintain
several projects and there are not enough hours in the day to stay on
top of all of the functional changes and bug reports let alone
formatting changes.

OK, I will refrain from going there too much then.



I think I will first start with a small PR to see if I am on the right tracks.



ForgeRock values your Privacy