From user-return-2946-archive-asf-public=cust-asf.ponee.io@jclouds.apache.org Sun Mar 21 21:16:23 2021 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mxout1-ec2-va.apache.org (mxout1-ec2-va.apache.org [3.227.148.255]) by mx-eu-01.ponee.io (Postfix) with ESMTPS id 4DB8018065E for ; Sun, 21 Mar 2021 22:16:23 +0100 (CET) Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mxout1-ec2-va.apache.org (ASF Mail Server at mxout1-ec2-va.apache.org) with SMTP id 858C541CF4 for ; Sun, 21 Mar 2021 21:16:22 +0000 (UTC) Received: (qmail 17861 invoked by uid 500); 21 Mar 2021 21:16:21 -0000 Mailing-List: contact user-help@jclouds.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@jclouds.apache.org Delivered-To: mailing list user@jclouds.apache.org Received: (qmail 17851 invoked by uid 99); 21 Mar 2021 21:16:21 -0000 Received: from spamproc1-he-de.apache.org (HELO spamproc1-he-de.apache.org) (116.203.196.100) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Mar 2021 21:16:21 +0000 Received: from localhost (localhost [127.0.0.1]) by spamproc1-he-de.apache.org (ASF Mail Server at spamproc1-he-de.apache.org) with ESMTP id 1D5051FF450 for ; Sun, 21 Mar 2021 21:16:21 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamproc1-he-de.apache.org X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamproc1-he-de.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mx1-ec2-va.apache.org ([116.203.227.195]) by localhost (spamproc1-he-de.apache.org [116.203.196.100]) (amavisd-new, port 10024) with ESMTP id seJg59lJcjsa for ; Sun, 21 Mar 2021 21:16:20 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.217.53; helo=mail-vs1-f53.google.com; envelope-from=jean-noel.rouvignac@forgerock.com; receiver= Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 102E5BD0A8 for ; Sun, 21 Mar 2021 21:16:19 +0000 (UTC) Received: by mail-vs1-f53.google.com with SMTP id s25so6443338vsa.1 for ; Sun, 21 Mar 2021 14:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=F1aoz5OMoZ0VMJ4W0Q6lJk8ESwtixzmOrP7PmsFJhjU=; b=cqBKkHybn/bnU+oY66WGjxbaAi2scc9rCsLGhJUrL4YT4SMbrvFOXspG9zocEBmsyH HdB6UMHjv2V6u6t8S2cJc/4p6jXTvwRrzDT/ajI5pzU55aX8C7+MMMTLzjFIHFrWIfbE dFP8B3Ds7G/RANimj89K69I6NcbbDv2f5HMV8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=F1aoz5OMoZ0VMJ4W0Q6lJk8ESwtixzmOrP7PmsFJhjU=; b=qqXiL7BdNS3MB7j2JQR+IoElnUfi+ueAWyBFPKP7I4TUL63lCMLWAf3w31nSMmP83l zbDmUtDAoAfAIL9gsTiL3BoXRaPFo7+7UmPdOthOMDBlL1uc816ZglRk51BaHDYHe/9Y mZtND+4fhQolClbJqPKaAdthJedAHr7bx50wlQeix39OyLZcXSw5E24ePP1B8p9kVCEq dspQfoBv993FA4oKQzdE5Yrh4hODMdcd/xa1gOngHhBhDhfcTdSa+1qfOPHk1OkImYEH mqyCi7BcLVOpFvP3JWheWi49CiLbtJjdoMMet4HE+xxK4NgjhkJ/Md/h/1RxgB9p9c8V 1Gtw== X-Gm-Message-State: AOAM533hsuInATKmv96faDikDzon4kWZKUaQYJNe0OjvXN15ReO8vyIO kqUoAzVqTX5fIXc0f9VwXOqBDue2I4vsVSHa1BsQfOdgXfof8Acf4Z/17lMdOHubUAUcIk3bliP ZFbUS6JNy/046sJ88NmbgsWNyRH8LJho= X-Google-Smtp-Source: ABdhPJzhOAmUOHSrc//T38N2xCy5UnetZooqss9mqwx2elUvBZQDFJI/dRq+S8csim3Wu+VBMo2rL+TvVSiYnMW8tmc= X-Received: by 2002:a05:6102:6c5:: with SMTP id m5mr7208327vsg.59.1616361378951; Sun, 21 Mar 2021 14:16:18 -0700 (PDT) MIME-Version: 1.0 References: <25b0e301-af80-768f-0ac5-626a383533f7@fritz-elfert.de> <29c99736-bea6-3c96-5ef0-fce9978063eb@fritz-elfert.de> In-Reply-To: From: =?UTF-8?Q?Jean=2DNo=C3=ABl_Rouvignac_=28ForgeRock=29?= Date: Sun, 21 Mar 2021 22:16:07 +0100 Message-ID: Subject: Re: [ANNOUNCE] Apache jclouds 2.3.0 released To: user@jclouds.apache.org Content-Type: multipart/alternative; boundary="000000000000d25cb005be12750a" --000000000000d25cb005be12750a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le dim. 21 mars 2021 =C3=A0 08:13, Andrew Gaul a =C3=A9cr= it : > On Thu, Mar 18, 2021 at 10:39:05AM +0100, Jean-No=C4=97l Rouvignac (Forge= Rock) > 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 > BaseComputeService.submitScriptOnNode(String id, String runScript, > RunScriptOptions options) > > is problematic but > > Set > BaseComputeService.resumeNodesMatching(Predicate > 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 publ= ic > > 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 cou= ld > > 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 doab= le > > 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. --=20 ForgeRock values your Privacy --000000000000d25cb005be12750a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Le=C2=A0dim. 21 mars 2021 =C3=A0=C2= =A008:13, Andrew Gaul <gaul@apache.or= g> a =C3=A9crit=C2=A0:
On Thu, Mar 18, 2021 at 10:39:05AM +0100, Jean-No=C4=97l Rouv= ignac (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 CompletableF= uture?
> 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.=C2=A0 There do= es
not seem to be an easy path forward here.=C2=A0 In the past we have done so= me
heavyweight @Deprecate-and-change-the-interface changes but these are a
lot of work.=C2=A0 I would add that the only important ones to change are t= he
interfaces, not the implementation.=C2=A0 Thus something like

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

is problematic but

Set<? extends NodeMetadata> BaseComputeService.resumeNodesMatching(Pr= edicate<? super NodeMetadata> filter)

is not.=C2=A0 In an ideal future Guava would be an implementation detail an= d
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= .=C2=A0 jclouds is not
alone in its Guava over-dependency.

Oh!= Excellent! Thanks for these pointers. I quickly looked for some but did no= t find any that was compelling.
=C2=A0
> I have noticed a lot of usages of Guava functional interfaces. These c= ould
> be replaced by JDK functional interfaces, but I have the same with pub= lic
> constructors / APIs. Plus I think I may have a problem with Guice if i= t
> uses reflection to instantiate the objects. I am only guessing this co= uld
> be a problem without any proof yet.
> Doing that, I realized there was a lot of code which could be using la= mbdas
> instead of creating subclasses of guavas functional interfaces.
> I think this would be a step in the right direction because lambdas ar= e not
> linked to the type they implement, so it becomes easier to switch from=
> guava functional interfaces to Java functional interfaces. This is doa= ble
> 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 bec= ause
> type inference has improved a lot with Java 8.
> Would you be OK with PRs removing unnecessary generic type parameters?=

-1 on cosmetic changes.=C2=A0 If you can cast these into an automated tool<= br> 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.=C2=A0 For example I hate 3-space indentation as much as everyo= ne
else but the costs far outweigh the benefits.=C2=A0 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 --000000000000d25cb005be12750a--