What's the advantage of POJO?

In my project I have a small data structure Key.

public class Key implements Serializable {

  private static final long serialVersionUID = 1L;

  public String db;
  public String ref;
  public Object id;

  protected Key() {
  }

  public Key(String db, String ref, Object id) {
    this.db = db;
    this.ref = ref;
    this.id = id;
  }
}

Yes this class is simple and every field is publicly accessible.

But someone has suggested I use POJO style classes instead but when I asked why they were unable to tell me.

In my opinion , calling getters and setters is slower than direct access to a field.

So why I must use POJO programming style?

Taken from Wikipedia:

POJO is an acronym for Plain Old Java Object. The name is used to emphasize that a given object is an ordinary Java Object, not a special object.

A POJO is usually simple so won't depend on other libraries, interfaces or annotations. This increases the chance that this can be reused in multiple project types (web, desktop, console etc).

As someone has already pointed out in the comments, your object is technically a POJO already however you have specifically asked about getters and setters which are more akin to JavaBeans.

There are a number of reasons I can think of for using getters and setters:

2. You might only want to get some of the values (I.E. read only values). With fields, clients can both get and set the values directly. Fields can be made read-only if they are marked as final although this doesn't always guarantee that they are immutable (see point 9).
3. Getter & setter methods allow you to change the underlying data type without breaking the public interface of your class which makes it (and your application) more robust and resilient to changes.
4. You might want to call some other code such as raising a notification when the value is obtained or changed. This is not possible with your current class.
5. You are exposing the implementation of your class which could be a security risk in some cases.
6. Java beans are designed around POJO's which means that if your class is not implemented as one it can't be used by certain tools and libraries that expect your class to adhere to these well established principles.
7. You can expose values that are not backed by a field I.E. calculated values such as getFullName() which is a concatenation of getFirstName() and getLastName() which are backed by fields.
8. You can add validation to your setter methods to ensure that the values being passed are correct. This ensures that your class is always in a valid state.
9. You can set a breakpoint in your getters and setters so that you can debug your code when the values are obtained or changed.
10. If the field is an object (I.E. not a primitive type) then the internal state of your class can be modified by other objects which can lead to bugs or security risks. You can protect against this scenario in your POJO's getter by returning a copy of the object so that clients can work with the data without affecting the state of your object. Note that having a final field does not always protect you against this sort of attack as clients can still make changes to the object being referenced (providing that object is itself mutable) you just cannot point the field at a different reference once it has been set.

Yes, accessing or setting the values via method calls may be slower than direct field access but the difference is barely noticeable and it certainly won't be the bottleneck in your program.

Whilst the advantages are clear this does not mean that getters and setters are a silver bullet. There are a number of 'gotchas' to consider when designing real world, robust scalable classes.

This answer to a very similar question looks at some considerations in detail when designing a class that has getters and setters. Although the suggestions may be more relevant depending on the type of class you are designing E.G. a class that forms part of an API in a large system as opposed to a simple data transfer object.

Also note that there may be certain scenarios where a class with direct field may be advantageous such as when speed is essential or memory is limited although this should only be considered after profiling your code and finding that it is actually a bottleneck.

Also be careful that you are not just wrapping all of your fields in getters and setters as this is really missing the point of encapsulation.

This answer provides a good summary of the reasons for choosing a POJO over a JavaBean style object with getters and setters.

Use private class variables and public getters and setters which will provide you Encapsulation.

Getters and setters, especially the simplest forms will just be inlined by the JIT compiler and thus remove the method call overhead. This sounds very much like premature optimisation. If you ever get a bottleneck, then profile and look where it occurs. I am fairly certain it'll be not in property accesses.

Get yourself the book Effective Java.

• Item 14, in public classes use accessor methods not public fields.

In this Joshua Bloch says there is nothing inheriently wrong with public fields in package-private or nested classes but strongly advises against use public classes.

He goes into much more detail on the subject, it's a great book, suggest you get a copy.

Imagine if some other programmer is using your code. If you don't provide setter and getter methods then he can directly call your variable and it surely will affect to your code. And it may lead to security issues So by providing POJO class you are forcing him to call on your methods rather than directly calling your Instance variables.