But!  Except that mentioned drawback, there is also possible benefit of
using it.  So, somebody may still find it useful.

To demonstrate potential benefits, let's define two short, simple, and
almost alternative test cases (SSAATC ;) ):

Case 1:

abstract class BaseBuilder<T extends BaseBuilder<T>> {

    T m1() {
        return (T) this;
    }

}

class ConcreteBuilder extends BaseBuilder<ConcreteBuilder> {

    ConcreteBuilder m2() {
        return this;
    }

}

Case 2:

abstract class BaseBuilder {

    BaseBuilder m1() {
        return this;
    }

}

class ConcreteBuilder extends BaseBuilder {

    ConcreteBuilder m1() {
        return (ConcreteBuilder) super.m1();
    }

    ConcreteBuilder m2() {
        return this;
    }

}

And define also an example usage for both of this cases:

ConcreteBuilder b = new ConcreteBuilder();
b.m1().m2();

Yes, nothing special so far.  But let's see now, how the above sample
usage will look after compilation with each of our test-cases...

Case 1 usage code:
   0:   new     #15; //class ConcreteBuilder
   3:   dup
   4:   invokespecial   #17; //Method ConcreteBuilder."<init>":()V
   7:   astore_0
   8:   aload_0
   9:   invokevirtual   #18; //Method ConcreteBuilder.m1:()LBaseBuilder;
   12:  checkcast       #15; //class ConcreteBuilder
   15:  invokevirtual   #22; //Method
ConcreteBuilder.m2:()LConcreteBuilder;
   18:  pop

Case 2 usage code:
   0:   new     #15; //class ConcreteBuilder
   3:   dup
   4:   invokespecial   #17; //Method ConcreteBuilder."<init>":()V
   7:   astore_0
   8:   aload_0
   9:   invokevirtual   #18; //Method
ConcreteBuilder.m1:()LConcreteBuilder;
   12:  invokevirtual   #22; //Method
ConcreteBuilder.m2:()LConcreteBuilder;
   15:  pop

See the difference?  Yes, additional cast in 1st case (line 12).

So, the hypothesis is now that in the latter case invocation of m1() may
perform better.

But let's see what exactly happens during each method invocation...

In case 1 m1() of BaseBuilder is invoked directly, and the result is
casted to ConcreteBuilder.

In case 2 m1() of ConcreteBuilder is invoked first, which in turn
invokes m1() of BaseBuilder, and then the result of it is casted to
ConcreteBuilder.

So, total number of casts is equal in both cases, thus they differs with
a single invocation more in a 2nd case only.

But wait.  What about reimplementing case 2 a bit?

Let's say, write it like that:

    ConcreteBuilder m1() {
        super.m1();
        return this;
    }

After that, there is no cast in 2nd case needed anymore.

So final score is:

1 cast, 1 invocation in 1st case vs. 2 invocations in 2nd case.

Assuming possible inlining of invocations by the JVM, it may most likely
happen that case 2 wins.

Of course, everything depends on the JVM.  So the above trivial
comparison may lay very far from reality.  But I hope it shows that
there is also possibility to benefit from non-generic covariant return
types use.

FWIW, my preference is still to use generic version.  But anyway, now I
have to go to sleep...  ;)

piotr

Ah, I see now.  You suggest to implement only *all known* builders'
methods by each builder.  Well, that's possible, and implementing all
dummies in a base class may even make it not hard to maintain, but it's
far from being as elegant as original Daniel's suggestion.  So, I still
prefer it over other ideas.

piotr

I can't make any sense of it.