We Keep Coding

Java getter/setter naming convention when also using records [duplicate]

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 convention dictates that one should name this method as getName().
Using both styles in the same code base does not look very nice. Migrating everything to records is not possible, as they are too limited to replace all use-cases.
Is there any official or semi-official guidelines how to name getters and setters after Java 14 in new code?

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:
Records are not the place to look for getters/setters syntactical sugar, as they are not meant to replace JavaBeans.
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.
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...

The record spec is now "final" as of Java 17 and this naming convention discrepancy has unfortunately not been addressed. I stumbled upon it when attempting to leverage Records as shallow holder classes to implement interfaces part of an existing domain model.
Whilst this isn't as neat a solution as I'd like, Records can have methods, so you could add "legacy" getters to your record, as in the following (contrived but simple) example.
public interface Nameable {
public String getName();
}
public record Person(String name) implements Nameable {
public String getName() {
return name; // or return name();
}
}
At least this allows client code to continue to use that tried and tested (over 20 years old) convention, which - let's face it - is used far more than in pure JavaBeans context.
You could say that the language designers have lived up to their remit of "not declaring war on boilerplate"

I stumbled up this when researching naming conventions for my project. Looking at the "recent" additions to the std lib (e.g. Path, FileSystem, HttpRequest, ...) the only more-or-less "pattern" I could detect was that .prop() implies direct, unmodified access to the field value, and thus existance of the field with that very type.
Whereas "getXXX" conveys that you cannot/should not assume the existence of a field. This property might be calculated, direct field access or read-only wrapped (e.g. List.copyOf) or converted.
So my conclusion is: if you want to communicate "structure" or enforce the precence of fields use .prop(). In all other cases stick to getXXX as it is more flexible (implementers can be entity classes, records or service classes.
Btw: I am aware that there are big offenders to this logic even in the jdk. e.g. BigDecimal that's why I focused on more recent additions.

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.

Java Enum type naming convention

What is the best practice of naming convention of enum
public enum SystemTypeEnum {
RRD, FFR, DDE
}
Currently the name is SystemTypeEnum. Is this ok or we should have name as SystemType
Would like to know best practice.

Disclaimer: I realize that my Answer can be considered opinionated, so my answer reflects my own experience.
I think it's better to rename to SystemType It's clear that its enum, all modern IDE show that. Following this logic, if you have, for example, interface
interface Calculator {
int plus(int a, int b);
int minus(int a, int b);
}
It should be renamed to CalculatorInterface - sounds weird, right?
Another example:
class Person {
String name;
int age;
}
Do you think its a good idea to rename it to PersonClass only because of its a class?
Bottom line, as I said, you can rely on IDE here - it will provide a visual hint for you for what it is.

Outcome
This is a highly opinion based topic, so I will try to keep this unbiased.
There are different standards and opinions and there is no very clear outcome to the discussion.
To my knowledge the most commonly used style is to not have a suffix or prefix.
Arguments
The discussion typically also includes pre- or suffixes for abstract classes and interfaces, not only enums. Also frequently seen are prefixes like E, A, I instead of suffix.
Some argue it does not add any useful additional information to the name and only clutters it. Some say it should not matter whether it is, lets say, and interface or a class. Some say it is the job of the IDE and not the name to indicate the type, for example with colors and icons. But there are also opinions in favor of that naming standard.
Style guidelines
A widely adopted style guideline is Googles style, quoting:
In Google Style, special prefixes or suffixes are not used. For example, these names are not Google Style: name_, mName, s_name and kName.
Another style that is commonly referred to is the style used in the JDK by the Java developers themselves, they also do not use a prefix or suffix.
But again, those are just some styles, there are also others.

Awkward naming convention of getter of Delegated boolean existential property

Please refer to Naming conventions for java methods that return boolean(No question mark)
to make a comparison about what I am NOT asking.
My question concerns properties derived from delegates embedded in a container object.
While the setters of all properties regardless of type is easily and conveniently prefixed with "set" (e.g. setValueRequired(blah) ), there are various types of boolean properties each whose getter is conventionally named {verb}{PropertyName}. e.g.,
the most common is existential, by convention is prefixed by "is". e.g. isEmpty().
possessive property, prefixed by "has", e.g. hasValue().
affirming necessity, prefixed by "requires", e.g. requiresResize(), providesResize().
By far, most property getters are somehow converted into existential properties. e.g. isRequireResize, isValued, etc. Therefore, my question concerns only expressing existential boolean properties (of a delegate class).
Let us say the container class is Printer, which contains the class Queue.
class Queue {
boolean empty, resettable, resizable;
}
class Printer {
Queue queue;
}
How then should Printer name its delegated properties for Queue? Because the following, by English comprehension convention, is awkward, as they sound like asking a question, not affirming its status.
isQueueEmpty()
isQueueResettable()
isQueueResizable()
The boolean property should be affirmative and not sound like asking a question. Therefore for comprehensible English, they should be
queueIsEmpty()
queueIsResettable()
queueIsResizable()
Or alternatively, could be
isEmptyQueue()
isResettableQueue()
isResizableQueue()
However, automated delegate method code generators invariably generate names isQueueEmpty(), isQueueResettable(), isQueueResizable().
That is awkward when placed into an if
if (isQueueResettable() && !isQueueEmpty()) resetQueue();
As this sounds better
if (isResizableQueue() && !isEmptyQueue()) resetQueue();
~
My Questions actually
If there a JSR recommending naming conventions of property getters? What is it? Certainly there must be, otherwise wouldn't all the code generators out there be limping around with ambiguous conventions?
If there is, does the JSR have recommendation for delegated boolean existential property getters?
If not JSR, at least some form of RFCs in Apache, JBoss, Eclipse, etc?
Don't you think the convention I recommend is better than code generators creating questioning getters?

I don't know much about JSR, but I am just trying to give my understanding.
You say isResettableQueue() sounds better than isQueueResettable to you( and probably to many others).
When you break up isResettableQueue() into is - Resettable - Queue, the main object(thing) about which you are talking comes into context at the last (in this case Queue).
But when you break up isQueueResettable() into is - Queue - Resettable, the main object(thing) about which you are talking comes into context at early stage (at least not at the last.
So you can tell Ok now I am talking about Queue for which I am checking if it is empty

Method names should start with a verb, so queueIsEmpty shouldn't be used.
I can't find any articles about naming conventions that mention this particular case, but the most natural choice would still be isQueueEmpty. isEmptyQueue would refer to this instead of this.queue. It would return whether "This object is an empty queue" instead of "This object's queue is empty".
Oracle also uses method names on the form isQueueEmpty.
Here are relevant method names defined in AbstractButton, JFrame, JTable and their super-classes:
isAlwaysOnTopSupported, isBackgroundSet, isBorderPainted, isCellEditable, isCellSelected, isColumnSelected, isContentAreaFilled, isCursorSet, isFocusPainted, isFocusTraversalPolicySet, isFontSet, isForegroundSet, isMaximumSizeSet, isMinimumSizeSet, isOptimizedDrawingEnabled, isPreferredSizeSet isRequestFocusEnabled, isRolloverEnabled, isRootPaneCheckingEnabled, isRowSelected

`name()` vs. `getName()` naming convention?

I have seen some projects (jsoup for example) are using this new getter/setter naming convention:
String name()
void name(String value)
instead of old getter/setter convetion:
String getName()
void setName(String value)
What are positive and negative aspects of each naming convention? When and why you think one should be preferred over the other?

The first example doesn't adhere to the JavaBeans specification [Warning PDF]. There are certain frameworks like Spring, that assume this naming convention, especially when you do something in EL like ${object.name}, which gets translated to object.getName(). This will fail if you don't follow the naming conventions (although there are ways to get around it).
Without getting into a discussion about when/if to use getters/setters, in general it's better to stick with the naming convention because there are fewer surprises that way, especially when you're integrating with third-party libraries or frameworks that expect things to be named according to convention.

Nothing except readability and API style.
Some APIs accept this style and some don't, like Spring injections and JSF can't recognize this syntax (they explicitly require get/set for properties).

I like to simply use name() when the object that I'm dealing with is immutable, i.e. I would never change the value of the name field. When I'm dealing with a mutable object, I would use the second convention you mentioned, simply because I think it is superior in terms of readability.

I always prefer using verbs for methods name, so this is valid also for getters and setters.
I use nouns only for variables.
Follow classic JavaBean standard make me feel more comfortable. :)

I prefer to use the shorter style if the library is low level and I want to make it clear this component is not a JavaBean.
If in doubt, I would use the JavaBean style.

What are the uses of getter/setters in Java? [duplicate]

This question already has answers here:
Why use getters and setters/accessors?
(37 answers)
Closed 7 years ago.
I have seen member variables given a private modifier and then using getter/setter methods just to set and get the values of the variable (in the name of standardization).
Why not then make the variable public itself (Other than cases like spring framework which depends on getter/setters for IOC etc). It serves the purpose.
In C# I have seen getter/setter with Capitalization of the member variable. Why not make the variable public itself?

In order to get a stable API from the first shot. The Java gurus thought that if later on, you might want to have some extra logic when setting/getting an instance member, you don't want to break existing API by replacing public fields with public methods. This is the main reason in Java.
In the case of C#, public properties are used instead of public fields because of binary interface compatibility. Someone asked a similar question right here, on SO.
So, it's all about encapsulating some logic while still preserving interface for... future proofing.

Even back in 2003 it was known that getter and setter methods are evil.

Because interfaces only allow for specifying methods, not variables. Interfaces are the building stones of API's.
Hence, to access a field through an interface, you need to have the getter and setter.

This is done so you can change the getter or setter implementation in your public API after you release it. Using public fields, you wouldn't be able to check values for validity.

Encapsulation
You also mentioned C# properties. These are really just getters/setters under the hood, but with a more concise syntax.

It's part of encapsulation: abstracting a class's interface (the "getters" and "setters") from its implementation (using an instance variable). While you might decide to implement the behaviour through direct access to an instance variable today, you might want to do it differently tomorrow. Say you need to retrieve the value over the network instead of storing it locally—if you have encapsulated the behaviour, that's a trivial change. If other objects are relying on direct access to an instance variable, though, you're stuck.

The most and foremost use for getters and setters in Java is to annoy the developers. The second most important use is to clutter the code with useless noise. Additionally, it forces you to use a different name for the same thing, depending on where you are (inside or outside the class). Not to forget the added ambiguity (do you call the getter inside the class or do you use the field directly?) Next, they are used to allow access to private data but that's just a minor side effect ;)
In other programming languages, the compiler will generate them for you (unless, of course, you provide your own implementations). In Delphi, for example, you have read and write modifiers for fields (just like private, static or final in Java). The define if you'll have a getter or setter generated for you.
Unlike the Delphi guys, the Java guys wanted everything to be explicit. "If it's not in the source, it's not there". So the only solution was to force people to write all the getters and setters manually. Even worse, people have to use a different name for the same thing.

Getters and setters may very well be the greatest lie ever told. They are considered a sign of good design, while the opposite is true. New programmers should be taught proper encapsulation, not to write dumb data carrier classes that contain nothing but getters and setters.
(The idea that you need getters and setters to future-proof your code if you want to change the implementation later on is an obvious case of YAGNI. But that is really beside the point.)

The most common reason is a poor understanding of encapsulation. When the developer believes that encapsulating stuff really just means getters & setters rather than encapsulating behavour.
The valid reasons for having getters/setters are:
1) You are making a generic¹ object such as JComponent. By using a getter/setter rather than direct access to the variable means that you can do some pre-processing on said variable first (such as validate it is with a set range) or change the underlying implementation (switching from an int to a BigInteger without changing the public API).
2) Your DI framework does not support ctor injection. By having just a setter you can ensure that the variable is only set once.
3) (Ties in with #1) To allow tools to interact with your object. By using such a simple convention then GUI tools can easily get all the settings for a given component. An example of this would be the UI builder in NetBeans.
¹ Of the not-Generic type. Bad word to use I know, please suggest an alternative.

Having a setter allows you
perform validation
to fire a property changed event if the new value is different from the previous value
In the case in question there is no need for getter and setter if the value is simply read or written.

Well,
OOP. ;)
Or to be a little more precise:
Getters and Setters are used to provide a defined interface to a classes
properties. Check the OOP link, it describes the concepts more in detail...
K

You'd need encapsulate those attributes if there are constraints for example or to make general validity checks or post events on changes or whatever. The basic use is hiding the attribute from the "outer world".

Some Java frameworks require them (JavaBeans I think).
-- Edit
Some posters are trying to say this is about encapsulation. It isn't.
Encapsulation is about hiding the implementation details of your object, and exposing only relevant functions.
Providing a get/set that does nothing but set a value does not accomplish this at all, and the only reason for them is:
Perform some additional validation before set/get
Get the variable from somewhere else
Integrate with frameworks (EJB)

There are several reasons:
Some Java APIs rely on them (e.g. Servlet API);
making non-final variable public is considered to be a bad style;
further code support: if sometime in future you`ll need to perform some actions before each access/mutation (get/set) of the variable, you will have less problems with it.
In C# constructions like
public int Age
{
get
{
return (int)(today() - m_BirthDate);
}
}
are are just syntactic sugar.

property idea is core in OOP (Object oriented programming). But problem is that Java introduce them not in core of language (syntax / JVM), but (probably few years later??? historics of Java say better) as convention: pair of consistent getters/setter is property in bean, concept of property is in libraries, not in core.
This generate problem in few libraries, framework. Is single getter a read only property or not? That is the question. I.e.in JPA entities if You want implement classic method (algorithm) beggining with "get" like getCurrentTine() is the best mark by #Transient to disable interpretation like property having value.
In other words, I like very much property concept in C# designed 10 years later and better. BTW C# property has getter/setter too, but sometimes/partially hidden, visible at low level debugging. Free from question "why getter" etc ...
In Java world is interesting to read about Groovy concept of property (hidden getter/setter in different way than C#) http://www.groovy-lang.org/objectorientation.html#_fields_and_properties
EDIT: from real life, every java object has getClass() method, tools from java.beans.BeanInfo package report this as property "class", but this not true. It isn't property (readonly property) in full sense. I imagine properties like C# (with his internal hidden name get_Something1) hasn't conflict with "functional" GetSomething2()