Annotations. Part two. lombok

Annotations. Part one, a little boring In this part, I decided to touch on the Lombok library as a well-known representative of Source annotations. With Runtime annotations in the next article. Once upon a time there was a java programmer, every day he wrote ordinary code, for example this:

package lombok;

public class Chelovek {
    private String name;
    private int age;

    public Chelovek(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public Chelovek() {
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        Chelovek chelovek = (Chelovek) o;

        if (age != chelovek.age) return false;
        return name != null ? name.equals(chelovek.name) : chelovek.name == null;
    }

    @Override
    public int hashCode() {
        int result = name != null ? name.hashCode() : 0;
        result = 31 * result + age;
        return result;
    }

    @Override
    public String toString() {
        return "Chelovek{" +
                "name='" + name + '\'' +
                ", age=" + age +
                '}';
    }
}

This is a typical class with only 2 fields (but sometimes there are more than 10-15 fields). Yes, of course, all this can be generated in the IDE, but damn, it takes up space. If there are 15-20 fields, all of them need getters, setters, constructors... Among all this, a couple of other methods that are invisible to the eye can easily get lost. How can I help such a programmer to write faster and less? Lombok. Straight into the heat, the same class but using Lombok:

package lombok;

@Data
public class Chelovek {
    private String name;
    private int age;
}

Yes, that's all. Cool? What will the @Data annotation do ? At the compilation stage, it will generate getters/setters for all fields, toString and redefine equals and hashCode according to the standards. You can install a plugin in the IDE and it will see all the methods that have not yet been created. I hope you, the reader, found it interesting, because what follows is a short introduction and links to details. Lombok also provides the opportunity to customize generation; all getters, setters, or hashcodes do not always need to be generated differently. Therefore, there are separate annotations (I think many of them do not need a description) @Getter/@Setter @ToString @EqualsAndHashCode @NoArgsConstructor, @RequiredArgsConstructor and @AllArgsConstructor @Log These are the most typical ones, the whole set can be viewed here var and val deserve special attention. It is possible to write like this:

package lombok;

import lombok.experimental.var;

@Data
public class Chelovek {
    private String name;
    private int age;

    public static void main(String[] args) {
        var chelovek = new Chelovek();
        chelovek.setAge(22);
        System.out.println(chelovek);
    }
}

Why is this necessary? For example, we have the RandomAccessFileChannel class. Well, why do we need to write it like this:

RandomAccessFileChannel channel = new RandomAccessFileChannel();

If possible like this:

var channel2 = new RandomAccessFileChannel();

In my opinion, this is not always acceptable. For example, we have an evil method that returns an evil map:

public static Map<List<Set<Integer>>, Set<List<String>>> evilMap(){
    return new HashMap<>();
}

if you call it like this:

Map<List<Set<Integer>>, Set<List<String>>> listSetMap = evilMap();

It is more or less clear what we are working with. If the call is like this:

var listSetMap = evilMap();

then who the hell knows what evilMap() returns, and until you look at the method itself, you won’t know. Why bother going through the sources? In general, you need to be more careful with this. Experimental thread: Here I would like to note the annotations: @UtilityClass It creates a private constructor and throws an exception there (so that hands dirty from reflection don’t get in here). And very nicely at the beginning of the class it tells us that there are utility methods. @Delegate Implements the delegation pattern. If you have a class that delegates something to another class, while making changes only to some methods, this annotation will save you from duplicating methods + will keep track of them. If a method is removed or added, she will notice it. Experimental annotations thread GITHUB Official website In order for the IDE to work normally with lombok, and not highlight methods as non-existent, you need to install the plugin. On the official website, there is a setup section where you can see how to connect the plugin for each IDE. As you can see, Lombok is popular. >5000 stars and >1000 forks. Spring uses lombok in her classes. If you have a spring in your project, look for it, maybe it pulled up the lombok, you just don’t know.