jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Noël Rouvignac (ForgeRock) <jean-noel.rouvig...@forgerock.com>
Subject Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Date Sun, 21 Mar 2021 21:16:07 GMT
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 <https://www.forgerock.com/your-privacy>

Mime
View raw message