Post Java-14 getter/setter naming convention

Question

Java 14 introduced records feature. Record creates getter with the same name as field, so one would write print(person.name()) for example. But old Java bean co

Answer 1

In Java records, object fields must be private and final. So there is just one kind of getter and one kind of setter possible.

In Java classes, object fields may be private or public. In the latter type of field, one can get or set them simply by adding a period and the field name, e.g.

 Employee emp = new Employee(); // Nullary constructor
 emp.name = "John Schmidt";     // Setter
 . . . 
 . . . 
 if (emp.name != "Buddy")       // Getter
 {
    emp.bonus = 100.00;
 }

Non-private fields are used a lot in Android apps to save memory and time extracting data. But there's no reason not to use them in Java where it's safe to do so.

Now, if you change away from the usual way in Java classes to something like that used in record types, e.g.

String name = emp.name();  // New getter convention for private field

you have a serious risk of confusion by code readers who might misinterpret this as a non-private object field.

And if you change the record getter to what is used in Java objects, i.e.

obj.getField()

then there is a risk of confusion by coder reviewers and possibly a compiler may treat it as a Java object, depending on execution decision criteria.

In short, it's a different type of object to the normal Java class or enum. Its accessors indicate this new type unambiguously. That's how I see it anyhow. Maybe someone on the Java development committee may be able to enlighten us further.

Answer 2

Quote from JEP 359:

It is not a goal to declare "war on boilerplate"; in particular, it is not a goal to address the problems of mutable classes using the JavaBean naming conventions.

My understanding, based on the same document is that records are transparent holders for shallowly immutable data.

That being said:

1. Records are not the place to look for getters/setters syntactical sugar, as they are not meant to replace JavaBeans.
2. I strongly agree with you that JavaBeans are too verbose. Maybe an additional feature (called beans instead of records) could be implemented - very similar behavior with the records feature but that would permit mutability. In that case, records and beans would not be mutually exclusive.
3. As it has been mentioned, records are in preview mode. Let's see what the feedback from community would be.

All in all, IMHO they are a step forward... I wrote this example set where you can see a code reduction to ~15% LOC from standard JavaBeans.

Also, note that records behave like normal classes: they can be declared top level or nested, they can be generic, they can implement interfaces (from the same document). You can actually partly simulate JavaBeans (only getters would make sense, though) by extracting an interface containing the getters - however that would be a lot of work and not a really clean solution...

So, based on the logic above, to address your question, no - I didn't see any (semi)official guideline for getters and setters and I don't think that there is a motivation for it right now because, again, records are not a replacement for JavaBeans...