Pular para o conteúdo principal

Eclipse Migration Toolkit for Java

 Eclipse Migration Toolkit for Java (EMT4J) simplifica a atualização de aplicativos Java

A Adoptium apresentou o Eclipse Migration Toolkit for Java (EMT4J), um projeto Eclipse de software livre capaz de analisar e atualizar aplicativos do Java 8 para o Java 11 e do Java 11 para o Java 17. O EMT4J suportará a atualização para futuras versões LTS.


As organizações aconselham manter o Java runtime atualizado para obter segurança e melhorias funcionais. Enquanto isso, as versões Java Long Term Support (LTS) serão lançadas a cada dois anos e projetos como o Spring Framework 6 agora requerem o Java 17. Infelizmente, a adoção de novas versões Java é relativamente lenta. Por exemplo, em 2022, quatro anos após seu lançamento, o Java 11 foi usado por menos de 49% dos aplicativos Java.


Atualizar um aplicativo para uma nova versão do Java significa que os desenvolvedores precisam resolver todos os problemas introduzidos pelas alterações e remoções dentro do Java. Isso inclui funcionalidades como a remoção dos pacotes Nashorn, J2EE e Java, uma alteração nas APIs e acesso aos componentes internos do Java que se tornaram mais restritos.


O EMT4J oferece um plugin Maven (ainda não disponível na central Maven), agente Java e solução de linha de comando para analisar incompatibilidades de projetos com novas versões Java e a saída é gravada nos formatos TXT, JSON ou HTML.


Para demonstrar o EMT4J, considere o seguinte aplicativo de exemplo que faz uma chamada para o método Thread.stop() que foi removido no Java 11:


Thread thread = new Thread();
thread.stop();

Depois de clonar o repositório Git e configurar as cadeias de ferramentas Maven para JDK 8 e JDK 11, o projeto pode ser construído com:


mvn clean package -Prelease

Isso resulta em um arquivo .zip no diretório emt4j-assembly/target que pode ser extraído. Dentro do diretório extraído, a análise pode ser iniciada. Por exemplo, na linha de comando:

java -cp "lib/analysis/*" org.eclipse.emt4j.analysis.AnalysisMain -f 8 -t 17
    -o java8to17.html /home/user/application/classes


Isso analisa os arquivos de classe no diretório especificado e exibe possíveis problemas ao atualizar do Java 8 para o Java 17 no arquivo java8to17.html. Alternativamente, os scripts .bat ou .sh no diretório bin do arquivo extraído podem ser usados para iniciar a análise da linha de comando. O arquivo README descreve todas as opções disponíveis para analisar classes e arquivos JAR.


O arquivo HTML resultante exibe a descrição, resolução e localização do problema:


1.1 Removed API Back to Content
1.1.1 Description
Many of these APIs were deprecated in previous releases and
    have been replaced by newer APIs.
1.1.2 How to fix
See corresponding JavaDoc.
1.1.3 Issues Context
Location: file:/home/user/application/classes/App.class,
    Target: java.lang.Thread.stop()V


Como alternativa, o agente EMT4J pode ser usado ao iniciar um aplicativo Java ou o plugin Maven ao criar o projeto.


O projeto contém conjuntos de regras para atualização de Java 8 para 11 e de Java 11 para 17. Por exemplo, a regra de API interna do JDK é usada para verificar se um aplicativo usa os componentes internos do JDK:


<rule desc="JDK internal API" type="reference-class"  
    match-type="by-package" class-package-file="jdk_internals.cfg"
    result-code="JDK_INTERNAL" must-contain-in-bytecode="true"
    sub-result-code="@{subResultCode}" priority="p4">
    <support-modes>
      <mode>agent</mode>
        <mode>class</mode>
    </support-modes>
</rule>


Os modos de suporte (modes) indicam se a regra pode ser usada com o modo de agente(agent) e/ou por meio da análise estática, modo de classe(class), com a linha de comando ou plugin Maven. Os pacotes de recursos de tradução são vinculados por meio do resultado do código, neste caso, JDK_INTERNAL, que mapeia para os arquivos de tradução JDK_INTERNAL.properties e JDK_INTERNAL_zh.properties dentro do diretório emt4j-common/src/main/resources/default/i18n.


O EMT4J verifica o aplicativo em busca de pacotes e classes como sun.nio e sun.reflect definidos no arquivo de pacote de classe jdk_internals.cfg no diretório emt4j-common/src/main/resources/default/rule/8to11/data/


A classe de referência do tipo de regra real está localizada dentro do diretório emt4j-common/src/main/java/org/eclipse/emt4j/common/rule/impl, pois a regra interna do JDK possui modes, agent e class.


@RuleImpl(type = "reference-class")
public class ReferenceClassRule extends ExecutableRule {


As regras existentes podem oferecer inspiração para adicionar regras personalizadas seguindo as instruções no arquivo README.



Fontes (Em Inglês):


https://www.infoq.com/news/2022/12/eclipse-migration-toolkit-java





Comentários

Postagens mais visitadas deste blog

Java Records

  Java Records Imutável, Simples e limpa Esta funcionalidade da linguagem apareceu pela primeira vez na versão 14 como experimental e assim continuou até a versão 15 . Agora liberada de forma definitiva no Java 16 . O objetivo é ser possível ter classes que atuam como portadores transparentes de dados imutáveis. Os registros podem ser considerados tuplas nominais. Ou seja, após criado, um record não pode mais ser alterado. Records oferece uma uma sintaxe compacta para declarar classes que são portadores transparentes para dados imutáveis superficiais visando reduzir significamente o detalhamento dessas classes e irá melhorar a capacidade de leitura e manutenção do código. Vamos seguir um exemplo de uma classe chamada Pessoa . O primeiro exemplo vamos utilizar o modo tradicional. public class Pessoa { private String nome; private int idade; public Pessoa (String nome, int idade) { super (); this .nome = nome; this .idade = idade; } public String getNo

Java 8 ao 18: Mudanças mais importantes na plataforma Java

    Vamos rever muitas das mudanças mais importantes na plataforma Java que aconteceram entre a versão 8 (2014) e 18 (2022)   O Java 8 foi lançado em março de 2014 e o Java 18 em março de 2022. São 8 anos de progresso, 203 JEPs (JDK Enhancement Proposals ), entre essas duas versões. Neste post, revisaremos as mudanças mais importantes e discutiremos os benefícios e desafios da adoção de versões mais recentes do JDK para novos aplicativos e para os mais antigos compilados com versões mais antigas. Desde a versão 9, o Java tem novos recursos a cada 6 meses e é muito difícil acompanhar essas novas mudanças. A maioria das informações na internet descreve as mudanças entre as duas últimas versões do Java. No entanto, se você estiver em uma situação semelhante à minha, não está usando uma das versões mais recentes do Java, mas uma das várias versões anteriores (Geralmente 8 ou 11 que são as versões de suporte estendido). Então é útil saber quais novos recursos foram adicionados d

O suporte de longo prazo e o que o LTS significa para o ecossistema Java

A arte do suporte de longo prazo e o que o LTS significa para o ecossistema Java Aqui está o que o Java 17 tem em comum com o Java 11 e o Java 8. Em junho de 2018, há pouco mais de três anos, a Oracle e outros participantes do ecossistema Java anunciaram uma mudança no modelo de cadência de lançamento para Java SE. Em vez de ter um lançamento principal planejado a cada dois ou quatro anos (que geralmente se torna de três a quatro anos), um novo modelo de lançamento de recursos de seis meses seria usado: a cada três anos, um lançamento seria designado como Long-Term Support (LTS) e receba apenas atualizações trimestrais de segurança, estabilidade e desempenho. Esse padrão foi emprestado descaradamente do modelo de lançamento do Mozilla Firefox, mas o ajustou para ficar mais alinhado com os requisitos de uma plataforma de desenvolvimento. A primeira versão do Java lançada sob esse modelo foi o Java SE 11. O lançamento do Java SE 17, o segundo lançamento do LTS sob o novo