Try Lombok

This is also super now. The reading is "Lombok".

Preparation

It was easiest to put it in Maven. In short, it doesn't matter if you put the classpath in lombok.jar.

pom.xml

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.16.16</version>
    <scope>compile</scope>
</dependency>

Automatic getter / setter generation

↓ This is

Product.java（@Before introducing Data)

public class Product implements Serializable {
    private String code;
    private String name;
    private BigDecimal price;

    /*Messed up*/
    public Product() {}
    public String getCode() { return this.code; }
    public String getName() { return this.name; }
    public BigDecimal getPrice() { return this.price; }
    public void setCode(String code) { this.code = code; }
    public void setName(String name) { this.name = name; }
    public void setPrice(BigDecimal price) { this.price = price; }
}

↓ It will be like this.

Product.java（@After introducing Data)

@Data
public class Product implements Serializable {
    private String code;
    private String name;
    private BigDecimal price;

    /*Refreshing!*/
}

The caller can call it normally, assuming that there is a getter / setter.

python

Product product = new Product();
product.setCode("0001");
product.setName("Product 01");
product.setPrice(BigDecimal.valueOf(10000L));

product.getCode();  // => 0001
product.getName();  // =>Product 01
product.getPrice(); // => 10,000

I hope the readability will improve.

Automatic builder pattern generation

By adding the @Builder annotation to Product.java mentioned above, the caller can also do the following.

python

Product product = Product.builder()
        .code("0001")
        .name("Product 01")
        .price(BigDecimal.valueOf(10000L))
        .build();

Somehow modern and cool.

By the way, is it OK to think that JavaBeans and Builder patterns are consistent? (The JavaBeans specification stated that "have a getter / setter" (* I do not say that I do not have a method other than getter / setter))

Treat checked exceptions like unchecked exceptions

You will not get a compile error even if you do not catch the checked exception at the caller. That is, ↓ this is

@Before the introduction of Sneaky Throws

private String encrypt(String src) {
    MessageDigest md;
    try {
        md = MessageDigest.getInstance("SHA-256");
    } catch (NoSuchAlgorithmException e) {
        throw new RuntimeException(e);
    }

    md.update(src.getBytes());
    return md.digest();
}

↓ It will be like this.

@After introducing Sneaky Throws

@SneakyThrows
private String encrypt(String src) {
    MessageDigest md = MessageDigest.getInstance("SHA-256");
    md.update(src.getBytes());
    return md.digest();
}

However, I haven't investigated it in detail, but I think it's better not to use it. I don't understand what the principle is, but it seems that I'm not wrapping the checked exception in RuntimeException, but just tricking the compiler into preventing the checked exception from becoming a compilation error. If you deliberately raise a NoSuchAlgorithmException in the source above, this will fly straight to the caller. This may have unexpected side effects with this. It would be nice if you knew that an exception would never occur like the above source (SHA-256 is always included).

In more detail, the coverage of Jacoco (0.8.2) was not 100% with the SneakyThrows annotation. If you say 100% coverage in your test plan, it can be a hassle later.

Digression

It's okay that getters / setters can be automatically generated, but I'm facing an essential contradiction that the JavaBeans setter itself may be against the idea of encapsulation in the first place. I'm not confident that I can give a satisfactory answer when asked, "Isn't it just a matter of making the field public without getters / setters?"