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. > 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. -- Andrew Gaul http://gaul.org/
