Pular para o conteúdo principal

Diferenças entre o Java 11 e Java 17 - Records e Sealed Classes

  



Diferenças entre Java 11 e 17 - Records e Sealed Classes


Neste segundo post vamos falar sobre Records e Sealed Classes.


Caso não tenha acompanhado a primeira parte sobre Text Blocks e Switch Expressions, está aqui.


Records


Records permitirão que você crie classes de dados imutáveis. Atualmente, você precisa, por exemplo, crie uma Classe de dados usando as funções de geração automática de seu IDE para gerar construtor, getters, hashCode, equals e toString ou você pode usar o Lombok para essa finalidade. No final, você acaba com algum código clichê ou acaba com uma dependência do Lombok em seu projeto.
public class GrapeClass {
private final Color color;
private final int nbrOfPits;

public GrapeClass(Color color, int nbrOfPits) {
this.color = color;
this.nbrOfPits = nbrOfPits;
}

public Color getColor() {
return color;
}

public int getNbrOfPits() {
return nbrOfPits;
}

@Override
public boolean equals(Object o) {
if (this == o)
return true;
if (o == null || getClass() != o.getClass())
return false;
GrapeClass that = (GrapeClass) o;
return nbrOfPits == that.nbrOfPits && color.equals(that.color);
}

@Override
public int hashCode() {
return Objects.hash(color, nbrOfPits);
}

@Override
public String toString() {
return "GrapeClass{" +
"color=" + color +
", nbrOfPits=" + nbrOfPits +
'}';
}
}
Execute alguns testes com a classe GrapeClass acima. Crie duas instâncias, imprima-as, compare-as, crie uma cópia e compare esta também.
private static void oldStyle() {
GrapeClass grape1 = new GrapeClass(Color.BLUE, 1);
GrapeClass grape2 = new GrapeClass(Color.WHITE, 2);
System.out.println("Grape 1 is " + grape1);
System.out.println("Grape 2 is " + grape2);
System.out.println("Grape 1 equals grape 2? " + grape1.equals(grape2));
GrapeClass grape1Copy = new GrapeClass(grape1.getColor(), grape1.getNbrOfPits());
System.out.println("Grape 1 equals its copy? " + grape1.equals(grape1Copy));
}
O resultado do teste é:
Grape 1 is GrapeClass{color=java.awt.Color[r=0,g=0,b=255], nbrOfPits=1}
Grape 2 is GrapeClass{color=java.awt.Color[r=255,g=255,b=255], nbrOfPits=2}
Grape 1 equals grape 2? false
Grape 1 equals its copy? true
A classe GrapeRecord tem a mesma funcionalidade do GrapeClass, mas é muito menos detalhada. Você cria um registro e indica quais devem ser os campos e pronto.
public record GrapeRecord(Color color, int nbrOfPits) {
}
Um Record pode ser definido em seu próprio arquivo, mas por ser tão compacto, também pode defini-lo onde for necessário. O teste acima reescrito com registros torna-se o seguinte:
private static void basicRecord() {
record GrapeRecord(Color color, int nbrOfPits) {}
GrapeRecord grape1 = new GrapeRecord(Color.BLUE, 1);
GrapeRecord grape2 = new GrapeRecord(Color.WHITE, 2);
System.out.println("Grape 1 is " + grape1);
System.out.println("Grape 2 is " + grape2);
System.out.println("Grape 1 equals grape 2? " + grape1.equals(grape2));
GrapeRecord grape1Copy = new GrapeRecord(grape1.color(), grape1.nbrOfPits());
System.out.println("Grape 1 equals its copy? " + grape1.equals(grape1Copy));
}
A saída é idêntica à anterior. É importante notar que as instâncias dos registros devem terminar em cópias idênticas. Adicionar funcionalidade extra em, por exemplo grape1.nbrOfPits() para fazer algum processamento e retornar um valor diferente do nbrOfPits inicial é uma má prática. É permitido, no entanto, mas você não deve fazer isso.
O construtor pode ser estendido com alguma validação de campo. Observe que a atribuição dos parâmetros aos campos do registro ocorre no final do construtor.
private static void basicRecordWithValidation() {
record GrapeRecord(Color color, int nbrOfPits) {
GrapeRecord {
System.out.println("Parameter color=" + color + ", Field color=" + this.color());
System.out.println("Parameter nbrOfPits=" + nbrOfPits + ", Field nbrOfPits=" + this.nbrOfPits());
if (color == null) {
throw new IllegalArgumentException("Color may not be null");
}
}
}
GrapeRecord grape1 = new GrapeRecord(Color.BLUE, 1);
System.out.println("Grape 1 is " + grape1);
GrapeRecord grapeNull = new GrapeRecord(null, 2);
}
A saída do teste acima mostra essa funcionalidade. Dentro do construtor, os valores do campo ainda são nulos, mas ao imprimir o registro, eles recebem um valor. A validação também faz o que deveria estar fazendo e lança uma IllegalArgumentException quando a cor é nula.
Parameter color=java.awt.Color[r=0,g=0,b=255], Field color=null
Parameter nbrOfPits=1, Field nbrOfPits=0
Grape 1 is GrapeRecord[color=java.awt.Color[r=0,g=0,b=255], nbrOfPits=1]
Parameter color=null, Field color=null
Parameter nbrOfPits=2, Field nbrOfPits=0
Exception in thread "main" java.lang.IllegalArgumentException: Color may not be null
	at com.giacom.java17.records.RecordTest$1GrapeRecord.<init>(RecordTest.java:12)
	at com.giacom.java17.records.RecordTest.basicRecordWithValidation(RecordTest.java:18)
	at com.giacom.java17.records.RecordTest.main(RecordTest.java:22)

Sealed Classes

Classes seladas darão a você mais controle sobre quais classes podem estender sua classe. Classes seladas são provavelmente mais um recurso útil para proprietários de bibliotecas. Uma classe está no Java 11 final ou pode ser estendida. Se você deseja controlar quais classes podem estender sua superclasse, você pode colocar todas as classes no mesmo pacote e dar visibilidade ao pacote de superclasse. Tudo está sob seu controle agora, porém, não é mais possível acessar a superclasse de fora do pacote. Vamos ver como isso funciona por meio de um exemplo.

Crie uma classe abstrata Fruit com visibilidade pública em algum pacote. No mesmo pacote, são criadas as classes finais Apple e Pear que estendem Fruit.
public abstract class Fruit {
}
public final class Apple extends Fruit {
}
public final class Pear extends Fruit {
}
Crie em outro pacote, um arquivo SealedClasses.java com um método problemSpace. Como você pode ver, as instâncias podem ser criadas para uma Apple, uma Pear e uma Apple podem ser atribuídas a uma Fruit. Além disso, também é possível criar uma classe Avocado que estende Fruit.
private static void problemSpace() {
Apple apple = new Apple();
Pear pear = new Pear();
Fruit fruit = apple;
class Avocado extends Fruit {
}
}
Suponha que você não deseja que alguém estenda uma Fruit. Nesse caso, você pode alterar a visibilidade da fruta para a visibilidade padrão (remova a palavra-chave puclic). O código acima não será mais compilado na atribuição de Apple a Fruit e na criação da classe Avocado. O último é desejado, mas queremos que uma Apple possa ser atribuída a uma Fruit. Isso pode ser resolvido em Java 17 com classes seladas.

No pacote que serão criadas as versões seladas de FruitSealed, AppleSealed e PearSealed. A única coisa a fazer é adicionar a palavra-chave sealed à classe Fruit e indicar com a palavra-chave permits quais classes podem estender essa Classe Selada. As subclasses precisam indicar se são final, sealed ou non-sealed. A superclasse não pode controlar se uma subclasse pode ser estendida e como pode ser estendida.
abstract sealed class FruitSealed permits AppleSealed, PearSealed {
}
public non-sealed class AppleSealed extends FruitSealed {
}
public final class PearSealed extends FruitSealed {
}
No método problemSpace, ainda é possível atribuir um AppleSealed a um FruitSealed, mas o Avocado não tem permissão para estender o FruitSealed. No entanto, é permitido estender AppleSealed porque esta subclasse é indicada como non-sealed.
private static void sealedClasses() {
AppleSealed apple = new AppleSealed();
PearSealed pear = new PearSealed();
FruitSealed fruit = apple;
class Avocado extends AppleSealed {};
}

Créditos e artigo original (em inglês)



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