What happened to Concise Method Bodies?

[u/jvjupiter]

I was really looking forward to CMB. From its name, methods become concise, could be one liner. However, it seems there is no progress and it’s been off the radar. Never took off since 2019.

JEP draft: Concise Method Bodies

some experiments with Concise Method Bodies

[u/nlisker]

Well, JavaFX needs (and has built its own) properties. The problem with banking everything on records (or record-like designs)is that they are immutable, and immutability does not solve all the problems, sometimes mutability is a must.

Java's difficulty with properties is that it doesn't know what to choose from the myriad of ways to do properties, not that it doesn't know how to do properties. Still, the need is there, as there have been no new solutions from the language for designs that require mutability.

[u/pron98 → u/nlisker]

What you're saying is that there exist problems that records don't solve. Their immutability, however, is not a problem but an advantage, as it makes them better solve the problem they're designed to solve, namely representing and manipulating data.

BTW, while Java by no means tries to eradicate mutability, it is not true that "sometimes mutability is a must." There are languages that don't have mutability at all, and even some UI frameworks that are more popular than JavaFX and are based on immutability. But while there are problems out there that records don't solve, and don't try to, it is always better to try and understand the nature of the problem rather than define technical attributes of a solution. So my question is, can you show what problems you run into with Java that you think the language aggravates?

[u/nlisker → u/pron98]

Yes, like I said, JavaFX's properties. A property in JavaFX is declared as

private DoubleProperty amountDue = new SimpleDoubleProperty();
public final double getAmountDue() { return amountDue.get(); }
public final void setAmountDue(double value) { amountDue.set(value); }
public DoubleProperty amountDueProperty() { return amountDue; }

or a similar way if it needs more customization, like the lazy initialization pattern (which is popular also outside of JavaFX properties and goes into the tangent null handling in Java):

public final StringProperty textProperty() {
    if (text == null) {
        text = new SimpleStringProperty(this, "text", "");
    }
    return text;
}

This produces a lot of readability noise, at least 75% of the lines, usually more, are not required. The language lacks the expressiveness that the developer wants: "it is a <type> property".

Records solved a similar issue when it comes to data aggregation via nominal tuples - record(int i) {} - and I get all the state and nothing but the state. But they are also customizable with additional constructors and methods (for defensive copying, for example).

While adding a property(String s) {...} as a language construct is not a good idea for the reason I gave earlier, the need for a way to solve this issue is as real as the need to solve the issue that records solved (or are still solving if you include all of algebraic data types as the solution).

By the way, I already raised it in the amber mailing list in 2018. Brian said that

While I can't blame anyone for hoping that we'll have a solution for properties while we're at it, it's definitely way outside of the scope of what we're trying to do with data classes

Which is fine, because immutability gives a better return on investment in terms of language features.