DEV Community: Gabriel Ronei

Monte seu Type-Safe builder

Gabriel Ronei — Fri, 02 Jul 2021 15:01:22 +0000

Menu: programadores + fome = código sobre comida

Dias atrás, após um dia de trabalho, estava estudando como de costume e me deu uma baita fome!

Resolvi terminar os estudos antes de ir jantar, mas um lanche do Subway não saia da minha cabeça...

Então, quando menos percebi, a classe que eu tinha criado era assim:




public class Lanche {

    private final Tamanho tamanho;
    private final Pao pao;
    private final Recheio recheio;
    private final Queijo queijo;
    private final List<Vegetais> vegetais;
    private final Molho molho;

    public Lanche(Tamanho tamanho, Pao pao, Recheio recheio,
                  Queijo queijo, List<Vegetais> vegetais,
                  Molho molho) {
        this.tamanho = tamanho;
        this.pao = pao;
        this.recheio = recheio;
        this.queijo = queijo;
        this.vegetais = vegetais;
        this.molho = molho;
    }

}

Aparentemente, essa classe é muito simples: é Java puro, não tem nada demais... Mas, como todo código, sempre tem algo a ser melhorado.

Vamos tentar olhar de forma crítica, decifrando o que podemos melhorar.

Não precisamos getters e setters. Partiremos da ideia que só criamos getters quando realmente for necessário. Como colocamos tudo o que precisamos no construtor, não temos o perigo de construir objetos inválidos.

Vamos ver como ficou a chamada para criar um lanche:



new Lanche(Tamanho.GRANDE,Pao.PARMESAO_OREGANO,Recheio.CHURRASCO,
Queijo.PRATO, List.of(Vegetal.ALFACE, Vegetal.CEBOLA),
Molho.CHIPOTLE);

Bom, então o que tem para ser melhorado? No livro Código Limpo (Clean Code de Robert Martin), no capítulo de funções há um item a respeito de parâmetros de funções (Function Arguments):

A quantidade ideal de parâmetros para uma função é zero (nulo).
Depois vem um (mônade), seguido de dois (díade).
Sempre que possivel, devem-se evitar três parâmetros (tríade).
Para mais de três, deve-se ter um motivo muito especial (políade) - mesmo assim não devem ser utilizados.

Pensando nessa frase, como faríamos para evitar chamar um construtor complexo ou vários setters no objeto criado?

Entrada: o padrão Builder

Foi exatamente por esse motivo que surgiu o padrão Builder, descrito no livro Padrões de Projetos (Design Patterns: Elements of Reusable Object-Oriented Software do GOF). O Builder é um padrão de projetos criacional que permite a separação da construção de um objeto complexo da sua representação.

O código ficaria assim:




public class Lanche {
    private final Tamanho tamanho;
    private final Pao pao;
    private final Recheio recheio;
    private final Queijo queijo;
    private final List<Vegetal> vegetais;
    private final Molho molho;

    private Lanche(LancheBuilder lancheBuilder) {
        this.tamanho = lancheBuilder.tamanho;
        this.pao = lancheBuilder.pao;
        this.recheio = lancheBuilder.recheio;
        this.queijo = lancheBuilder.queijo;
        this.vegetais = lancheBuilder.vegetais;
        this.molho = lancheBuilder.molho;
    }

    public static LancheBuilder umLanche() {
        return new LancheBuilder();
    }

    public static class LancheBuilder {
        private Tamanho tamanho;
        private Pao pao;
        private Recheio recheio;
        private Queijo queijo;
        private List<Vegetal> vegetais;
        private Molho molho;

        //Nao deixando chamar o construtor de fora desta classe
        private LancheBuilder() {
        }

        public LancheBuilder grande() {
            this.tamanho = Tamanho.GRANDE;
            return this;
        }

        public LancheBuilder normal() {
            this.tamanho = Tamanho.NORMAL;
            return this;
        }

        public LancheBuilder comPao(Pao pao) {
            this.pao = pao;
            return this;
        }

        public LancheBuilder comRecheio(Recheio recheio) {
            this.recheio = recheio;
            return this;
        }

        public LancheBuilder comQueijo(Queijo queijo) {
            this.queijo = queijo;
            return this;
        }

        public LancheBuilder comVegetais(Vegetal... vegetais) {
            this.vegetais = List.of(vegetais);
            return this;
        }

        public LancheBuilder comMolho(Molho molho) {
            this.molho = molho;
            return this;
        }

        public Lanche constroi() {
            return new Lanche(this);
        }
    }
}

E a chamada fica assim:



Lanche.umLanche().grande()
                .comPao(PARMESAO_OREGANO)
                .comMolho(CHIPOTLE)
                .comQueijo(PRATO)
                .comRecheio(CHURRASCO)
                .comVegetais(ALFACE, CEBOLA)
                .constroi();

Veja que deixei o construtor da classe Lanche como privado e disponibilizei o método umLanche, que devolve um Builder. Isso está descrito no livro Java Efetivo (Effective Java de Joshua Bloch) e é chamado de static factory. Diferente dos construtores conseguimos nomeá-los, fazendo com que fiquem mais descritivos. Além disso, podemos retornar um objeto que a princípio não é o mesmo de nossa classe.

Agora nosso problema foi resolvido: em nossa classe Lanche só temos um parâmetro no construtor: o LancheBuilder.

É o mais próximo do número de parâmetros ideal (zero/nulo).

Não sei se todos já foram a lanchonete chamada Subway, mas há regras para montar nosso lanche:

Costuma a funcionar um pouquinho diferente da foto, por isso vou detalhar a forma que os atendentes fazem:

Devemos escolher o recheio e o pão
Escolhemos um tamanho
Escolhemos o queijo
Escolhemos os vegetais
Por último, podemos ou não escolher um molho

Essa lanchonete funciona exatamente nessa ordem. Com isso, conseguimos identificar problemas em nossa solução atual: da forma que fizemos o Builder, não temos uma ordem de chamada, perceba que chamei tudo fora de ordem e veja o que conseguimos fazer:



Lanche.umLanche().constroi();

Nós pulamos todas as etapas, construimos um objeto em um estado inválido. OK, poderíamos lançar uma exceção caso algo esteja faltando.

Mas será que nós conseguiríamos pegar todos os erros em tempo de compilação? Aí, não precisaríamos esperar o projeto rodar para descobrir. O código nem seria compilado. Mas e agora? Como fazer para garantir que só vamos construir o objeto se passarmos por todas as etapas?

Prato Principal: os Type-safe Builders

Os Type-safe (ou Staged, ou Telescopic, ou Step) Builders nos auxiliam nas limitações que temos ao utilizar os Builders comuns.

A ideia é bem simples: aproveitar o sistema de tipos do Java para garantir que no momento de compilação todas as propriedades sejam definidas antes que a instância da classe seja construída.

Então, utilizando em nosso projeto a ideia do Type-safe Builder, construiremos nosso objeto em passos. Uma possível solução é a seguinte:



public class Lanche {
    private final Tamanho tamanho;
    private final Pao pao;
    private final Recheio recheio;
    private final Queijo queijo;
    private final List<Vegetal> vegetais;
    private final Molho molho;

    private Lanche(LanchePassoFinalBuilder lanchePassoFinalBuilder) {
        this.tamanho = lanchePassoFinalBuilder.tamanho;
        this.pao = lanchePassoFinalBuilder.pao;
        this.recheio = lanchePassoFinalBuilder.recheio;
        this.queijo = lanchePassoFinalBuilder.queijo;
        this.vegetais = lanchePassoFinalBuilder.vegetais;
        this.molho = lanchePassoFinalBuilder.molho;
    }

    public static LancheBuilder umLanche(Recheio recheio, Pao pao) {
        return new LancheBuilder(recheio, pao);
    }

    static class LancheBuilder {
        private final Recheio recheio;
        private final Pao pao;

        private LancheBuilder(Recheio recheio, Pao pao) {
            this.recheio = recheio;
            this.pao = pao;
        }

        public LancheTerceiroPassoBuilder grande() {
            return new LancheTerceiroPassoBuilder(recheio, pao,
                    Tamanho.GRANDE);
        }

        public LancheTerceiroPassoBuilder normal() {
            return new LancheTerceiroPassoBuilder(recheio, pao,
                    Tamanho.NORMAL);
        }
    }

    static class LancheTerceiroPassoBuilder {
        private final Recheio recheio;
        private final Pao pao;
        private final Tamanho tamanho;

        public LancheTerceiroPassoBuilder(Recheio recheio,
                                          Pao pao,
                                          Tamanho tamanho) {
            this.recheio = recheio;
            this.pao = pao;
            this.tamanho = tamanho;
        }

        public LancheQuartoPassoBuilder comQueijo(Queijo queijo) {
            return new LancheQuartoPassoBuilder(recheio,
                    pao, tamanho, queijo);
        }
    }

    static class LancheQuartoPassoBuilder {
        private final Recheio recheio;
        private final Pao pao;
        private final Tamanho tamanho;
        private final Queijo queijo;

        public LancheQuartoPassoBuilder(Recheio recheio,
                                        Pao pao, Tamanho tamanho,
                                        Queijo queijo) {
            this.recheio = recheio;
            this.pao = pao;
            this.tamanho = tamanho;
            this.queijo = queijo;
        }

        public LanchePassoFinalBuilder comVegetais(Vegetal... vegetais) {
            return new LanchePassoFinalBuilder(tamanho,
                    recheio, pao,
                    queijo, List.of(vegetais));
        }
    }

    static class LanchePassoFinalBuilder {
        private final Tamanho tamanho;
        private final Recheio recheio;
        private final Pao pao;
        private final Queijo queijo;
        private final List<Vegetal> vegetais;
        private Molho molho;

        public LanchePassoFinalBuilder(Tamanho tamanho,
                                       Recheio recheio, Pao pao,
                                       Queijo queijo,
                                       List<Vegetal> vegetais) {
            this.tamanho = tamanho;
            this.recheio = recheio;
            this.pao = pao;
            this.queijo = queijo;
            this.vegetais = vegetais;
        }

        public LanchePassoFinalBuilder comMolho(Molho molho) {
            this.molho = molho;
            return this;
        }

        public Lanche build() {
            return new Lanche(this);
        }
    }
}

Dessa forma, não conseguimos pular nenhuma etapa obrigatória. Temos que seguir certinho as etapas para construção. E o melhor de tudo: quem for utilizar o Builder, não precisa conhecer a regra de negocio da lanchonete previamente. O código esta sucinto e claro o suficiente para que funcione como sua própria documentação.

Lembre-se: escrevemos códigos para que outras pessoas entendam.

O resultado da criação de um lanche com o Type-safe Builder ficou assim:



Lanche.umLanche(CHURRASCO, TRES_QUEIJOS)
                .grande()
                .comQueijo(PRATO)
                .comVegetais(CEBOLA, TOMATE, ALFACE)
                .comMolho(CHIPOTLE)
                .build();

Os Type-safe Builders lidam muito bem com parâmetros opcionais. Basta trazê-los para perto da classe que permite a criação final do objeto.

Em Java, temos uma biblioteca chamada jilt, que pode nos auxiliar na criação de Type-safe Builders. Linguagens como o Kotlin também ajudam na criação desse tipo de Builder.

Sobremesa: removendo indireções e finalizando com classe(ou interfaces?)

Podemos dizer que criamos uma interface fluente.

Fizemos o nosso design de código de uma forma que ao ler nós conseguimos entendê-lo como uma simples e bela frase de uma música.

Porém, vou te mostrar que ainda temos algumas indireções que podem gerar conflitos:

Viu só? Quando digitamos um ponto e nossa IDE nos auxilia em qual método chamar, aparecem os passos internos.

Isso acontece porque definimos nossas classes internas de Lanche (os Builders dos passos) como pacote-privado (package-private).

Como será que podemos fazer para restringir ainda mais o acesso dessas classes internas?

Não podemos apenas definir como privado (private), pois assim seriam inacessíveis fora da classe Lanche.

Em Java, nós temos as interfaces. Assim como as classes (não internas), podem ser apenas pacote-privado ou públicas.

Com as interfaces, conseguimos garantir uma API, um contrato que é assinado independente de quem a implemente.

As interfaces de definição dos passos do nosso Type-safe Builder ficariam assim:



public interface CriacaoLanchePassos {

    interface LancheBuilder {
        LancheTerceiroPasso grande();
        LancheTerceiroPasso normal();
    }

    interface LancheTerceiroPasso {
        LancheQuartoPasso comQueijo(Queijo queijo);
    }

    interface LancheQuartoPasso {
        LanchePassoFinal comVegetais(Vegetal... vegetais);
    }

    interface LanchePassoFinal {
        LanchePassoFinal comMolho(Molho molho);
        Lanche build();
    }
}

Nossas implementações dessa interfaces podem ser classes internas e privadas.

Bom, seguindo essas alterações, nosso código ficou:



public class Lanche {
    private final Tamanho tamanho;
    private final Pao pao;
    private final Recheio recheio;
    private final Queijo queijo;
    private final List<Vegetal> vegetais;
    private final Molho molho;

    private Lanche(LanchePassoFinalBuilder lanchePassoFinalBuilder) {
        this.tamanho = lanchePassoFinalBuilder.tamanho;
        this.pao = lanchePassoFinalBuilder.pao;
        this.recheio = lanchePassoFinalBuilder.recheio;
        this.queijo = lanchePassoFinalBuilder.queijo;
        this.vegetais = lanchePassoFinalBuilder.vegetais;
        this.molho = lanchePassoFinalBuilder.molho;
    }

    public static CriacaoLanchePassos.LancheBuilder umLanche(Recheio recheio, Pao pao) {
        return new LancheBuilder(recheio, pao);
    }

    private static class LancheBuilder implements CriacaoLanchePassos.LancheBuilder {
        private final Recheio recheio;
        private final Pao pao;

        public LancheBuilder(Recheio recheio, Pao pao) {
            this.recheio = recheio;
            this.pao = pao;
        }

        public CriacaoLanchePassos.LancheTerceiroPasso grande() {
            return new LancheTerceiroPassoBuilder(recheio, pao,
                    Tamanho.GRANDE);
        }

        public CriacaoLanchePassos.LancheTerceiroPasso normal() {
            return new LancheTerceiroPassoBuilder(recheio, pao,
                    Tamanho.NORMAL);
        }
    }

    private static class LancheTerceiroPassoBuilder implements CriacaoLanchePassos.LancheTerceiroPasso {
        private final Recheio recheio;
        private final Pao pao;
        private final Tamanho tamanho;

        private LancheTerceiroPassoBuilder(Recheio recheio,
                                          Pao pao,
                                          Tamanho tamanho) {
            this.recheio = recheio;
            this.pao = pao;
            this.tamanho = tamanho;
        }

        public CriacaoLanchePassos.LancheQuartoPasso comQueijo(Queijo queijo) {
            return new LancheQuartoPassoBuilder(recheio,
                    pao, tamanho, queijo);
        }
    }


    private static class LancheQuartoPassoBuilder implements CriacaoLanchePassos.LancheQuartoPasso {
        private final Recheio recheio;
        private final Pao pao;
        private final Tamanho tamanho;
        private final Queijo queijo;

        private LancheQuartoPassoBuilder(Recheio recheio,
                                        Pao pao, Tamanho tamanho,
                                        Queijo queijo) {
            this.recheio = recheio;
            this.pao = pao;
            this.tamanho = tamanho;
            this.queijo = queijo;
        }

        public CriacaoLanchePassos.LanchePassoFinal comVegetais(Vegetal... vegetais) {
            return new LanchePassoFinalBuilder(tamanho,
                    recheio, pao,
                    queijo, List.of(vegetais));
        }
    }

    private static class LanchePassoFinalBuilder implements CriacaoLanchePassos.LanchePassoFinal {
        private final Tamanho tamanho;
        private final Recheio recheio;
        private final Pao pao;
        private final Queijo queijo;
        private final List<Vegetal> vegetais;
        private Molho molho;

        private LanchePassoFinalBuilder(Tamanho tamanho,
                                       Recheio recheio, Pao pao,
                                       Queijo queijo,
                                       List<Vegetal> vegetais) {
            this.tamanho = tamanho;
            this.recheio = recheio;
            this.pao = pao;
            this.queijo = queijo;
            this.vegetais = vegetais;
        }

        public LanchePassoFinalBuilder comMolho(Molho molho) {
            this.molho = molho;
            return this;
        }

        public Lanche build() {
            return new Lanche(this);
        }
    }
}

Com isso, não temos mais acesso a detalhes internos de implementação:

Conseguimos seguir estritamente a ideia de ocultação de informação (information hiding) ou encapsulamento. Não temos nenhuma indireção, temos apenas uma API fluente. Códigos assim são comumente encontrados em bibliotecas com um bom design de código.

Você pode encontrar o código desse post neste repositório: github.com/gabrielronei/typesafebuilder-subway-exemplo.

O repositório está divido em três branches, que são os três principais pontos que chegamos até aqui: primeira_refatoracao, segunda_refatoracao e terceira_refatoracao.

Existem várias soluções possiveis para esse código, porém essa foi uma solução que achei legal e quis mostrar para vocês.

Espero que a ideia tenha ficado clara e que vocês consigam aproveitar algo desse tipo no dia-a-dia.

Lembrem-se, como tudo em Arquitetura/Design de Software, não é uma bala de prata. Sendo utilizada em excesso pode causar problemas e dificuldade de entendimento.

Mas é algo muito interessante que podemos ter como uma carta em nossa manga! :)

Referências:

Padrão Builder - https://bit.ly/3AiNfH0
Artigo do criador do JILT - https://bit.ly/3x7YKPS

Livros

Código limpo (Clean code de Robert C. Martin) - https://amzn.to/3jzA8vh
Java Efetivo (Effective Java de Joshua Bloch) - https://amzn.to/3yeSd67
Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos(Design Patterns: Elements of Reusable Object-Oriented Software de GOF) - https://amzn.to/3h99Sq9

Gerenciando versões com SDKMAN!

Gabriel Ronei — Mon, 10 May 2021 17:29:30 +0000

Bom, quando comecei a programar, colegas me contaram sobre a existência de uma ferramenta que podia me auxiliar ao instalar as versões do Java. Porém, como eu tinha acabado de começar, fiquei confuso sobre como essa ferramenta funcionava exatamente, então deixei para um futuro.

Anos se passaram, até que em um belo dia, sentei para trabalhar e, como de costume, fui olhar os Pull Requests para revisar os códigos da equipe. Me deparei com um PR que atualizava a versão do Java em nosso projeto. Nesse momento varias coisas vieram na minha cabeça:

Puts, isso vai dar um trabalho, atualizar Path, configurar IDE...
Onde será que tem essa versão? De qual distribuidora eu baixo?
Será que é tranquilo instalar ou requer muito esforço?
E se eu definir como default e quebrar meus outros projetos?

... e um pensamento veio mais forte ainda: e agora quem poderá me defender?

Eu, o SDKMAN!

Software Development Kit Manager (algo como, Gerente de Kit de Desenvolvimento de Software) é uma ferramenta que gerencia as versões paralelas de vários SDKs, tambem chamados de "candidates" (candidatos). O nome mais conhecido é SDKMAN!, assim mesmo, com exclamação no final.

O SDKMAN! nos auxilia para tratar de nossas configurações como se fossem um "detalhe", algo simples, algo que não deveríamos dedicar muito esforço. Afinal, devemos deixar a árdua labuta para nossas práticas de código.

Fornecendo uma interface via linha de comando (CLI) que nos ajuda a instalar, listar, alternar e remover esses candidatos.

Além disso, podemos destacar alguns pontos positivos, como:

By Developers, for Developers: o SDKMAN! se encarrega de definir as variáveis de ambiente para nós
Java all the way down: Podemos instalar vários candidatos para JVM, assim como Java, Groovy, Scala, Kotlin, Maven, Gradle e etc...
Lightweight: Super leve, escrito em Bash (e funciona com zsh também). Só precisa de cURL e zip/unzip instalados.
Multi-platform: Roda em sistemas UNIX, como Mac OSX, Linux, e etc.
APIs e Open-Source: Novos clientes podem ser facilmente escritos consumindo a API deles e é um projeto open source.
Podemos adicionar também nossa própria versão para ser gerenciada pelo SDKMAN!.

Como instalar?

Vamos seguir nas versões UNIX like, pois são as que eu tenho mais intimidade.

Eu não utilizo o Windows como meu sistema operacional padrão, mas em sua própria documentação, diz que hoje tem algumas formas disponíveis para instalar. Caso alguém tenha alguma dúvida, pode mandar que tento ajudar de alguma forma.

Primeiro vamos abrir o terminal e rodar o comando:



curl -s "https://get.sdkman.io" | bash

E pronto, o SDKMAN! está instalado. Temos duas opções:

Podemos apenas reiniciar o terminal.
Rodar o comando source para adicionar ao nosso arquivo de configuração:



source "$HOME/.sdkman/bin/sdkman-init.sh"

Feito isso, podemos rodar o comando sdk version e ver que o SDKMAN! foi devidamente instalado.

Mas e agora? Como utilizar?

Se instalar foi fácil, utilizar é mais ainda! Vamos ver os candidatos disponíveis com o comando:



sdk list

Apareceram vários né? Vamos pensar no nosso problema inicial que era atualizar a versão do Java para fazer o review do código, então podemos adicionar ao comando list o candidato que queremos:



sdk list java

O resultado será algo parecido com:



================================================================================
Available Java Versions
================================================================================
 Vendor        | Use | Version      | Dist    | Status     | Identifier
--------------------------------------------------------------------------------
 AdoptOpenJDK  |     | 16.0.1.j9    | adpt    |            | 16.0.1.j9-adpt      
               |     | 16.0.1.hs    | adpt    |            | 16.0.1.hs-adpt     
...
 Alibaba       |     | 11.0.9.4     | albba   |            | 11.0.9.4-albba      
               |     | 8.5.5        | albba   |            | 8.5.5-albba         
 Amazon        |     | 16.0.1.9.1   | amzn    |            | 16.0.1.9.1-amzn     
               |     | 16.0.0.36.1  | amzn    |            | 16.0.0.36.1-amzn
...

Olha que legal! O SDKMAN! trouxe de uma forma um pouco diferente, né? Apareceram as versões disponíveis do Java. Vamos entender um pouco sobre cada coluna:

Vendor: mais conhecido como o fornecedor daquela versão.
Use: flag para dizer qual é a versão que estamos utilizando atualmente.
Version: qual versão do Java do candidatos.
Dist: distribuição, um slug para o fornecedor.
Status: mostra quais versões temos instaladas.
Identifier: um ID, é unico e é utilizado para instalar ou remover uma versão.

Agora que temos uma ideia do que é cada coluna, para instalar nos precisamos passar ao sdk a identificação da versão que queremos instalar. No nosso caso vai ser a 16.0.1.9.1-amzn. Então, rodamos o comando:



sdk install java 16.0.1.9.1-amzn

Durante essa instalação, seremos perguntados se queremos definir como a versão default do Java. Pode confirmar!

E está lá, rodando o comando java --version e o javac --version vemos que a versão é a 16 que acabamos de instalar! Fácil, né?

Agora só falta configurarmos em nossas IDEs. Pode ser na de sua preferência. Aqui, irei mostrar tanto no IntelliJ quanto no Eclipse, que são as que tenho maior intimidade.

IntelliJ

Abra o IntelliJ e vá em File > Project Structure.
Na parte de Project SDK clique em Edit.
Clique no + (add new sdk) e passe o caminho do SDK para que aponte para a current, que sempre irá a versão configurada no SDKMAN!. No meu caso é algo como: /home/gabriel/.sdkman/candidates/java/current%. Se você quiser, pode apontar para algum dos candidatos que você baixou pelo SDKMAN!.
Após adicionado, volte em Project Structure e em SDKs selecione a versão que você acabou de criar.
No menu Run, vá em Edit configurations, para editar as configurações de execução do projeto.
Expanda Environment e, em JRE, selecione a versão current do Java que você instalada pelo SDKMAN!.

Eclipse

Abra o Eclipse e vá em Project > Properties e entre na aba Libraries.
Clique em Modulepath > Add Library e selecione JRE System Library.
Apos clicar em Next, selecione Workspace default JRE (X.x.x.x.x-slug).
Pra confirmar se tudo está correto, ao lado do icone de Run, clique na setinha para baixo e entre em Run Configurations.
Clique na aba JRE, e veja se está marcado Project JRE. Pronto!

Comandos extras:

Alternar entre as versões que você tem instalada em sua máquina, é super simples!

Para usar uma versão (temporariamente):



sdk use java 15.0.2.7.1-amzn

Quando você abrir um outro terminal, a versão será a default.

Para definir como default (permanentemente):



sdk default java 15.0.2.7.1-amzn

Para ver qual é a versão atual:



sdk current java

Para desinstalar uma versão:



sdk uninstall java 16.0.1.9.1-amzn

Ao usar o SDKMAN!, as versões são baixadas para sua máquina. Para atualizar as versões dos candidatos, rode o comando:



sdk update

Como desinstalar:

Caso não tenha acostumado, teve algum problema ou algo relacionado, é fácil desintalar o SDKMAN!.

Podemos usar o comando:



 rm -rf ~/.sdkman

Agora é onde está o pulo do gato! Temos que abrir algum dos arquivos de inicialização, como o .bashrc, .bash_profile, .profile e/ou .zshrc em um editor de textos.

No fim do arquivo você deve encontrar o bloco a seguir:



#THIS MUST BE AT THE END OF THE FILE FOR SDKMAN TO WORK!!!

[[ -s "/home/dudette/.sdkman/bin/sdkman-init.sh" ]] && source "/home/dudette/.

sdkman/bin/sdkman-init.sh"

Apague este bloco por completo e salve. Prontinho! O SDKMAN! está completamente deletado de sua máquina!

Referências:

A documentação do SDKMAN! é bem completinha, você pode ver em: https://sdkman.io/

Diferença entre as distribuições das JDKs: https://sdkman.io/jdks

Pronto, agora você pode fazer a mesma coisa para tudo que o SDKMAN! oferece suporte :)