This is a controversial issue (as you can see) because a bunch of dogma and misunderstandings is mixed up with the reasonable concerns regarding the issue of getters and setters. But in short, there is nothing wrong with @Data and it does not break encapsulation.

Why use getters and setters rather than just making fields public?

Because getters/setters provide encapsulation. It is an implementation detail whether some property of an object is stored in a field or is calculated or generated on the fly or fetched from somewhere else. If you expose a value as a public field, and then later decide change to calculating the value on the fly, then you need to modify all clients accessing the field. Clearly this is bad. Getter/setters setter solve this, since they hide the implementation from clients.

But if the getter/setter just read and write an underlying private field isn't is just as bad?

No! The point is the encapsulation allows you to change the implementation without affecting clients. A field might still be a perfectly fine way to store value, as long as clients does not have to know or care.

But isn't autogenerating getters/setters from fields breaking encapsulation?

No the encapsulation is still there! Is is just a convenient way to write getter/setter-pairs which uses an underlying field. For the viewpoint of a client this is just like a regular getter/setter pair. If you decide to rewrite the implementation you can still do it without affecting the client.

But some say getter/setters are always bad!

There is a separate controversy, where some believe the getter/setter pattern is always bad, regardless of the underlying implementation. The idea is that you should not set or get values from objects, rather any interaction between objects should be modeled as messages where one object asks another object to do something. This is mostly a piece of dogma from the early days of object-oriented thinking. The thinking now is that for certain patterns (e.g. value objects, data transfer object) getters/setters may be perfectly appropriate.

This is a controversial issue (as you can see) because a bunch of dogma and misunderstandings is mixed up with the reasonable concerns regarding the issue of getters and setters. But in short, there is nothing wrong with @Data and it does not break encapsulation.

Why use getters and setters rather than public fields?

Because getters/setters provide encapsulation. If you expose a value as a public field and then later change to calculating the value on the fly, then you need to modify all clients accessing the field. Clearly this is bad. It is an implementation detail whether some property of an object is stored in a field, is generated on the fly or is fetched from somewhere else, so the difference should not be exposed to clients. Getter/setters setter solve this, since they hide the implementation.

But if the getter/setter just reflect an underlying private field isn't it just as bad?

No! The point is the encapsulation allows you to change the implementation without affecting clients. A field might still be a perfectly fine way to store value, as long as clients does not have to know or care.

But isn't autogenerating getters/setters from fields breaking encapsulation?

No the encapsulation is still there! @Data annotations are just a convenient way to write getter/setter-pairs which uses an underlying field. For the viewpoint of a client this is just like a regular getter/setter pair. If you decide to rewrite the implementation you can still do it without affecting the client. So you get the best of both worlds: encapsulation and concise syntax.

But some say getter/setters are always bad!

There is a separate controversy, where some believe the getter/setter pattern is always bad, regardless of the underlying implementation. The idea is that you should not set or get values from objects, rather any interaction between objects should be modeled as messages where one object asks another object to do something. This is mostly a piece of dogma from the early days of object-oriented thinking. The thinking now is that for certain patterns (e.g. value objects, data transfer object) getters/setters may be perfectly appropriate.

A bunch of dogma and misunderstandings is mixed up with the reasonable concerns regarding the issue of getters and setters.

Why use getters and setters rather than just making fields public?

Because getters/setters provide encapsulation. It is an implementation detail whether some property of an object is stored in a field or is calculated or generated on the fly or fetched from somewhere else. If you expose a value as a public field, and then later decide change to calculating the value on the fly, then you need to modify all clients accessing the field. Clearly this is bad. Getter/setters setter solve this, since they hide the implementation from clients.

But if the getter/setter just read and write an underlying private field isn't is just as bad?

No! The point is the encapsulation allows you to change the implementation without affecting clients. A field might still be a perfectly fine way to store value, as long as clients does not have to know or care.

But isn't autogenerating getters/setters from fields breaking encapsulation?

No the encapsulation is still there! Is is just a convenient way to write getter/setter-pairs which uses an underlying field. For the viewpoint of a client this is just like a regular getter/setter pair. If you decide to rewrite the implementation you can still do it without affecting the client.

But some say getter/setters are always bad!

There is a separate controversy, where some believe the getter/setter pattern is always bad, regardless of the underlying implementation. The idea is that you should not set or get values from objects, rather any interaction between objects should be modeled as messages where one object asks another object to do something. This is mostly a piece of dogma from the early days of object-oriented thinking. The thinking now is that for certain patterns (e.g. value objects, data transfer object) getters/setters may be perfectly appropriate.

This is a controversial issue (as you can see) because a bunch of dogma and misunderstandings is mixed up with the reasonable concerns regarding the issue of getters and setters. But in short, there is nothing wrong with @Data and it does not break encapsulation.

Why use getters and setters rather than just making fields public?

Because getters/setters provide encapsulation. It is an implementation detail whether some property of an object is stored in a field or is calculated or generated on the fly or fetched from somewhere else. If you expose a value as a public field, and then later decide change to calculating the value on the fly, then you need to modify all clients accessing the field. Clearly this is bad. Getter/setters setter solve this, since they hide the implementation from clients.

But if the getter/setter just read and write an underlying private field isn't is just as bad?

No! The point is the encapsulation allows you to change the implementation without affecting clients. A field might still be a perfectly fine way to store value, as long as clients does not have to know or care.

But isn't autogenerating getters/setters from fields breaking encapsulation?

No the encapsulation is still there! Is is just a convenient way to write getter/setter-pairs which uses an underlying field. For the viewpoint of a client this is just like a regular getter/setter pair. If you decide to rewrite the implementation you can still do it without affecting the client.

But some say getter/setters are always bad!

There is a separate controversy, where some believe the getter/setter pattern is always bad, regardless of the underlying implementation. The idea is that you should not set or get values from objects, rather any interaction between objects should be modeled as messages where one object asks another object to do something. This is mostly a piece of dogma from the early days of object-oriented thinking. The thinking now is that for certain patterns (e.g. value objects, data transfer object) getters/setters may be perfectly appropriate.