Le dim. 21 mars 2021 à 08:13, Andrew Gaul <g...@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 <https://www.forgerock.com/your-privacy>
