<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="" style="font-family: HelveticaNeue;"><font color="#929292" class=""><i class="">/* I sent the following to discuss@ mailing list yesterday. (wrong list for the topic) I hope this will be more appropriate mailing list */</i></font></div><div class="" style="font-family: HelveticaNeue;"><br class=""></div><div class="" style="font-family: HelveticaNeue;">Hi all,</div><div class="" style="font-family: HelveticaNeue;"><br class=""></div><span style="font-family: HelveticaNeue;" class="">this is a request for feedback on a topic that has been on my mind for a few weeks. I have written a short document in JEP format and would like to ask you to comment if you find the described proposal useful.</span><div class="" style="font-family: HelveticaNeue;"><br class=""></div><div class="" style="font-family: HelveticaNeue;">Thanks,</div><div class="" style="font-family: HelveticaNeue;">Tomas Blesa</div><div class="" style="font-family: HelveticaNeue;">__________________________________</div><div class="" style="font-family: HelveticaNeue;"><br class=""></div><div class=""><div class=""><font face="HelveticaNeue" class="">Summary</font></div><div class=""><font face="HelveticaNeue" class="">-------</font></div><div class=""><font face="HelveticaNeue" class="">Enhance the Java language syntax to better support the method chaining (named parameter idiom) programming pattern.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Goals</font></div><div class=""><font face="HelveticaNeue" class="">-----</font></div><div class=""><font face="HelveticaNeue" class="">The primary goal is to remove unnecessary boilerplate code in class methods designed for type-safe chained calls, especially when combined with inheritance.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Motivation</font></div><div class=""><font face="HelveticaNeue" class="">----------</font></div><div class=""><font face="HelveticaNeue" class="">[Method chaining](<a href="https://en.wikipedia.org/wiki/Method_chaining" class="">https://en.wikipedia.org/wiki/Method_chaining</a>) is a widely used and popular programming pattern, particularly in creating libraries (APIs) or configuration objects. Programmers can easily create a method that returns `this` with a method signature that specifies the returning type of the containing class.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class Shape {</font></div><div class=""><font face="HelveticaNeue" class="">    public Shape scale(double ratio) {</font></div><div class=""><font face="HelveticaNeue" class="">        // recalculate all points</font></div><div class=""><font face="HelveticaNeue" class="">        return this;</font></div><div class=""><font face="HelveticaNeue" class="">    }</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">The problem arises when we combine this pattern with inheritance. We can lose type information when calling the method on a subclass. For example, let's create two subclasses of the `Shape` superclass:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class Rectangle extends Shape {</font></div><div class=""><font face="HelveticaNeue" class="">    public Rectangle roundCorners(double pixels) {</font></div><div class=""><font face="HelveticaNeue" class="">        // ...</font></div><div class=""><font face="HelveticaNeue" class="">        return this;</font></div><div class=""><font face="HelveticaNeue" class="">    }</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">class Circle extends Shape {</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Now, imagine the following piece of code using the mini-library above:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">var myRect = new Rectangle().scale(1.2).roundCorners(10);</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">The code won't compile because `scale()` returns the type `Shape`, which doesn't have the `roundCorners` method. There is also a problem even without the final `roundCorners()` call:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">var myRect = new Rectangle().scale(1.2);</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">The inferred type of `myRect` is `Shape` and not `Rectangle`, so the following line will also be invalid:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">myRect.roundCorners(10);</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Straightforward solutions to the problem could be:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">1) Override the `scale()` method in all subclasses and change the return type:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class Rectangle extends Shape {</font></div><div class=""><font face="HelveticaNeue" class="">    // ...</font></div><div class=""><font face="HelveticaNeue" class="">    @Override</font></div><div class=""><font face="HelveticaNeue" class="">    public Rectangle scale(double ratio) {</font></div><div class=""><font face="HelveticaNeue" class="">        super.scale(ratio);</font></div><div class=""><font face="HelveticaNeue" class="">        return this;</font></div><div class=""><font face="HelveticaNeue" class="">    }       </font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">2) Split object construction and method calls:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">var myRect = new Rectangle();</font></div><div class=""><font face="HelveticaNeue" class="">myRect.scale(1.2);</font></div><div class=""><font face="HelveticaNeue" class="">myRect.roundCorners(10);</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">3) Partial solution - reorder chained calls (if possible):</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">var myRect = new Rectangle();</font></div><div class=""><font face="HelveticaNeue" class="">myRect.roundCorners(10).scale(1.2); // roundCorners called first</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">All of these solutions add unnecessary lines of code, and as the library of shapes grows, keeping the desired return type will introduce more and more boilerplate code.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Description</font></div><div class=""><font face="HelveticaNeue" class="">-----------</font></div><div class=""><font face="HelveticaNeue" class="">The proposed solution to the problem described in the previous section is to extend the Java syntax for the returned type in method signatures:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class Shape {</font></div><div class=""><font face="HelveticaNeue" class="">    public this scale(double ratio) { // <=== returns this</font></div><div class=""><font face="HelveticaNeue" class="">        // recalculate all points</font></div><div class=""><font face="HelveticaNeue" class="">        return this;</font></div><div class=""><font face="HelveticaNeue" class="">    }</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Methods declared or defined as returning `this` can only return the instance on which they are called. The following code will be type-safe and perfectly valid:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">var myRect =                     // inferred Rectangle type</font></div><div class=""><font face="HelveticaNeue" class="">    new Rectangle()              // returns Rectangle instance</font></div><div class=""><font face="HelveticaNeue" class="">    .scale(1.2)                  // returns Rectangle instance</font></div><div class=""><font face="HelveticaNeue" class="">    .roundCorners(10);           // returns Rectangle instance</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">The constructed type `Rectangle` is preserved throughout the entire call chain.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">It is possible to override methods returning `this`, but the subclass' implementation must also be declared with the `this` keyword instead of a concrete returning type.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">It is even possible to remove the explicit return statement altogether:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class Shape {</font></div><div class=""><font face="HelveticaNeue" class="">    public this scale(double ratio) {</font></div><div class=""><font face="HelveticaNeue" class="">        // recalculate all points</font></div><div class=""><font face="HelveticaNeue" class="">    }</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Or simply remove the value `this` from the return statement:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class Shape {</font></div><div class=""><font face="HelveticaNeue" class="">    public this scale(double ratio) {</font></div><div class=""><font face="HelveticaNeue" class="">        // recalculate all points</font></div><div class=""><font face="HelveticaNeue" class="">        if (condition) return;         // <== automatically returns this</font></div><div class=""><font face="HelveticaNeue" class="">        // do something else</font></div><div class=""><font face="HelveticaNeue" class="">    }</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">In fact, methods returning `this` can be compiled to the same bytecode as methods returning `void`. This is because the instance reference (and the returned value) is already known to the caller, eliminating the need to pass that value back through the call stack. As a result, both CPU cycles and memory are saved.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">In the Java world, it is common to create getters and setters according to the Java Beans specification in the form of `getProperty`/`setProperty` pairs or `isProperty`/`setProperty`. Setters are defined as returning `void`. These setters can be more useful if defined as returning `this`:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class Customer {</font></div><div class=""><font face="HelveticaNeue" class="">    public this setFirstname() { ... }</font></div><div class=""><font face="HelveticaNeue" class="">    public this setSurname() { ... }</font></div><div class=""><font face="HelveticaNeue" class="">    public this setEmail() { ... }</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">This allows for more concise usage when constructing and configuring an instance without adding more code:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">customers.add(</font></div><div class=""><font face="HelveticaNeue" class="">    new Customer()</font></div><div class=""><font face="HelveticaNeue" class="">        .setFirstname(resultSet.getString(1))</font></div><div class=""><font face="HelveticaNeue" class="">        .setSurname(resultSet.getString(2))</font></div><div class=""><font face="HelveticaNeue" class="">        .setEmail(resultSet.getString(3))</font></div><div class=""><font face="HelveticaNeue" class="">);</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">It is also possible to declare an interface with methods returning `this`:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">interface Shape {</font></div><div class=""><font face="HelveticaNeue" class="">    this scale(double ratio);</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">In this case, all implementing classes must define the method as returning `this`.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">The proposed syntax is a bit less useful for enums or records, as neither of them allows for inheritance. But enums and records can also implement interfaces and for this reason and for overall consistency, "return this" syntax should be allowed for enums and records.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">To accommodate the syntax with the Java Reflection API, it will probably be required to create a special final placeholder class `This` (with an uppercase "T"), similar to `java.lang.Void`.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Alternatives</font></div><div class=""><font face="HelveticaNeue" class="">------------</font></div><div class=""><font face="HelveticaNeue" class="">It is probably possible to help auto-generate overriding methods in subclasses using annotation processing, but this option wasn't fully explored. However, such an approach would add extra unnecessary code to compiled subclasses and go against the primary goal of reducing boilerplate.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Risks and Assumptions</font></div><div class=""><font face="HelveticaNeue" class="">---------------------</font></div><div class=""><font face="HelveticaNeue" class="">The proposed syntax is likely to break the compatibility of library-dependent code whose author decides to switch to the "return this" syntax between versions.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Older code that looks like this:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class MyUglyShape extends Shape {</font></div><div class=""><font face="HelveticaNeue" class="">    @Override</font></div><div class=""><font face="HelveticaNeue" class="">    public MyUglyShape scale(double ratio) {</font></div><div class=""><font face="HelveticaNeue" class="">        return this;</font></div><div class=""><font face="HelveticaNeue" class="">    }</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">will have to be rewritten as:</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class MyUglyShape extends Shape {</font></div><div class=""><font face="HelveticaNeue" class="">    @Override</font></div><div class=""><font face="HelveticaNeue" class="">    public this scale(double ratio) {    // signature change</font></div><div class=""><font face="HelveticaNeue" class="">        // optional removal of the return this statement</font></div><div class=""><font face="HelveticaNeue" class="">    }</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">or </font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">```java</font></div><div class=""><font face="HelveticaNeue" class="">class MyUglyShape extends Shape {</font></div><div class=""><font face="HelveticaNeue" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>// override removed</font></div><div class=""><font face="HelveticaNeue" class="">}</font></div><div class=""><font face="HelveticaNeue" class="">```</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">This problem can be mitigated with the help of smart IDEs automatically suggesting such refactoring.</font></div><div class=""><font face="HelveticaNeue" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class="">Another possible risk is breaking old code that relies on the Reflection API for scanning the returning types of methods.</font></div></div></body></html>