Java beans have a readability problem. Not the pattern itself — fields plus getters and setters is fine, and a great deal of the ecosystem still relies on it — but the house style the average enterprise codebase wraps around it. Six lines of boilerplate Javadoc and braces for a one-word concept, repeated for every property, until a class with eight fields scrolls for two pages and tells you nothing you didn’t already know from the field name.

The fix is small. Treat the property as the unit. One Javadoc that says something useful, a single-line getter, a single-line setter, grouped together. The eye scans the list of properties, not the cycles of accessor ceremony around each one.

Compare:

private float hue;
private float saturation;
private float lightness;

/** Hue; 0.0 = red, 1/3 = green, 2/3 = blue, wraps at 1.0. */
public float getHue() {return hue;}
public void setHue(float hue) {this.hue = hue;}

/** Saturation; 0.0 = grey, 1.0 = full colour. */
public float getSaturation() {return saturation;}
public void setSaturation(float saturation) {this.saturation = saturation;}

/** Lightness; 0.0 = black, 0.5 = pure hue, 1.0 = white. */
public float getLightness() {return lightness;}
public void setLightness(float lightness) {this.lightness = lightness;}

…against the Enterprise-Java rendition of the same three properties, which weighs in at roughly forty lines of Gets the hue. @return the hue and tells the reader exactly nothing that the identifier hue did not already tell them. The compact form is denser, but density here is a feature: every line carries meaning, and the Javadoc finally gets to say something real — what the value means, what range it lives in, what happens at the edges — instead of restating the method signature in English.

“But the Google Java Style Guide…”

This is the objection that comes up every time, and it deserves a direct answer. Section 4.1.3 says non-empty blocks follow K&R, with line breaks after { and before }. So strictly read, public float getHue() {return hue;} is non-conforming.

A few things are worth noting:

• Google’s style guide is a house style for Google, not the Java specification. It is one reasonable set of choices among many. Adopting it wholesale is fine; treating any deviation as a defect is not.
• The rule was written for methods, in the general sense — methods that contain logic worth reading on its own lines. Trivial accessors are not really methods in that sense; they are the syntactic price Java charges for not having first-class properties. Kotlin, C#, Scala, and Java records all acknowledge this by making the accessor disappear entirely. The compact form is the closest plain-Java approximation.
• If your team has standardised on Google style and runs a formatter that enforces it, follow the formatter. Consistency inside a codebase beats any individual style argument. The point of this post is not “Google is wrong” but “the compact form is a defensible, widely-used choice, and it exists for a real reason.”

The IntelliJ remark — “the IDE will fold these for you, so why do it in source?” — is a fair instinct but answers a different question. Code folding is a viewing convenience for one reader on one machine. The source file is what gets reviewed in pull requests, diffed in git log -p, rendered on GitHub, pasted into chat, and read by everyone who isn’t sitting in front of your IntelliJ. Optimising the file is more durable than optimising the view.

Who uses this style

Single-line properties are a common style across enterprise and open-source projects. Single-line accessors and grouped property blocks show up across:

• IntelliJ IDEA’s own “simple methods in one line” formatting option, on by default in many profiles.
• Older Spring Boot modules, real-world Hibernate entities, pre-Kotlin Android code, Jenkins core and plugins, large parts of the Hadoop ecosystem, and older Elasticsearch.
• Framework code that relies on JavaBean conventions and ends up with many trivial accessors by necessity.
• Many many enterprise systems.

It tends to be preferred by developers maintaining legacy code, teams that deliberately avoid Lombok (to keep builds simple and stack traces honest), teams that can’t yet adopt records for compatibility reasons, and people who want their accessors to be explicit, debuggable, and non-generated.

Modern alternatives

If you can use them, the better answer is usually to not write the accessors at all:

• Records (record Color(float hue, float saturation, float lightness) {}) where immutability is acceptable — and for value-like data, it usually is.
• Lombok @Getter @Setter if your team is comfortable with the build-time magic.
• Immutables or AutoValue for code-generated value types with builders.
• Kotlin data classes if the language choice is open.

The compact accessor block is the right tool only when you’re stuck writing JavaBeans by hand — which, in plenty of real codebases, is still most of the time.

The rule, in one line

When you must write accessors by hand, write the property — Javadoc, getter & setter — as one visually cohesive block, and let the Javadoc say something the identifier doesn’t already say. The reader’s eye will thank you, and the class will start to read like a description of its data instead of a deposition about it.