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.
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? Cheers, Jean-Noel Le jeu. 18 mars 2021 à 09:47, Andrew Gaul <g...@apache.org> a écrit : > On Thu, Mar 18, 2021 at 09:38:19AM +0100, Jean-Noėl Rouvignac (ForgeRock) > wrote: > > Thanks for highlighting ListenableFuture for a start. Given the size of > > jclouds (about 400kLOC of production code with a stupid wc -l) and my > > inexperience of its codebase, I need help to know where to start. :) > > I'll see what I can do about it. Do you want to create an issue that > > describes this work and what you expect out of it? > > > > You also mentioned that some public APIs return `ImmutableMap`. Have > these > > methods been deprecated in favour of an overload returning a `Map`? > > I think opening a JIRA issue describing the possible improvements makes > sense since this spans several PRs (and we should open issues for all > functional changes to make release notes work anyway). ImmutableMap is > another good place to start -- some style guides suggest returning > ImmutableMap instead of Map to hint at immutability but this > unnecessarily makes the interface reliant on Guava. I would have to > look at interface-maven-plugin again to see everything but unfortunately > I ran into issues with the way jclouds uses public access across > subpackages. > > -- > Andrew Gaul > http://gaul.org/ > -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
