<p>Modify the superclass's builder to use an F-bound (aka the Curiously Recurring Template Pattern).</p>

<pre><code>public interface SuperClassBuilderInterface&lt;SELF extends SuperClassBuilderInterface&lt;SELF&gt;&gt; {
    SELF withS1(String s1);
    // etc.
    Superclass build();
}
</code></pre>

<p>Then you have:</p>

<pre><code>class SuperClassBuilder&lt;SELF extends SuperClassBuilder&lt;SELF&gt;&gt; implements SuperClassBuilderInterface&lt;SELF&gt;

interface ABuilderInterface&lt;SELF extends ABuilderInterface&lt;SELF&gt;&gt; extends SuperClassBuilderInterface&lt;SELF&gt;

class ABuilder extends SuperClassBuilder&lt;ABuilder&gt; implements ABuilderInterface&lt;ABuilder&gt;
</code></pre>

<p>Note that the implementation of <code>SuperClassBuilder</code> must contain unchecked casts of the form <code>return (SELF)this;</code>. The type system is theoretically powerful enough to not need this, but the resulting encoding would probably be very ugly (see <a href="https://arxiv.org/pdf/1605.05274.pdf" rel="nofollow noreferrer">this</a>) and it's likely not worth it.</p>

<p>EDIT: This is what @shmosel meant</p>
Java Builder pattern with inheritance
<p>I want to implement a builder pattern with static inner classes for lets say classes A with fields (a1, a2, a3), B with fields (b1, b2) and C with fields (c1), whereas all share fields (s1, s2) from super class SuperClass:</p>

<pre><code>public class A extends SuperClass {
    private final String a1;
    ...

    private A(ABuilder builder) {
        super(builder);
        this.a1 = builder.a1;
        ...
    }

    public static class ABuilder extends SuperClassBuilder implements ABuilderInterface {
        private String a1;
        ...

        @Override
        public ABuilder withA1(String a1) {
            this.a1 = a1;
            return this;
        }
        ...

        @Override
        public SuperClass build() {
            return new A(this);
        }
    }
}
</code></pre>

<p>Accordingly for B and C the builders just differ that they have their own fields and implement their own interfaces (BBuilderInterface and CBuilderInterface), whereas these interfaces are only defining which methods are to be implemented:</p>

<pre><code>public interface ABuilderInterface extends SuperClassBuilderInterface {
    ABuilderInterface withA1(String a1);
    ...
}
...&lt;interfaces for B and C&gt;

public interface SuperClassBuilderInterface {
   SuperClassBuilderInterface withS1(String s1);
   ...
   SuperClass build();
}

// Usage of the builders:
public SuperClass foo() {
    return new A.ABuilder()
        .withA1(...) // returns ABuilderInterface
        ...
        .withS1(...) // returns SuperClassBuilderInterface
        ...
        .build();
}

public abstract class SuperClass {
private final String s1;
...

protected SuperClass(SuperClassBuilder builder) {
    this.s1 = builder.s1;
    ...
}

protected static abstract class SuperClassBuilder implements SuperClassBuilderInterface {
    private String s1;
    ...

    @Override
    public SuperClassBuilder withS1(String s1) {
        this.s1 = s1;
        return this;
    }
    ...

    @Override
    public abstract SuperClass build();
}
}
</code></pre>

<p>Now you can spot the limitation that when I use the builder I have to pay attention to call the with... methods related to the child class first, then chain the ones for the super class, which is not a big of a deal, but still not sure whether good practice.
On the other side I could add the with... methods of the children classes to the super class interface all together and then the limitation is gone, but then I have an interface with mixed with... methods of different child classes.</p>

<p>Which one would you prefer/suggest?</p>