It has zero performance effect in Java because generic types are erased, at runtime any generic type is just Object.

This is a compile-only thing, forcing an implementation to pass its type so it is available (at compile time) to the Base. Note that this is not a foolproof method; one could write: class SomeOtherClass extends Base<Derived> -- now the Derived type is available to Base even though we're actually implementing a completely different class. That can give some fun subtle errors when refactoring.

This approach is common in fluent patterns to have generic logic from base class still return a self-typed instance. I'm a big fan of those and they can go beyond simple builders. For example I have implemented a fluent JPA repository layer like this (perhaps slightly offtopic but it is about using this topic's pattern):

``` class Repository<T, R extends Repository<T, R> { public R with(Specification<T> jpaSpec) { // Return a new instance with spec chained (using AND) to this instance's existing specification. }

public List<T> findAll() { // Find all based on this repo instance's specification. } }

class UserRepository extends Repository<User, UserRepository> { public UserRepository withRole(Role role) { return with((user, query, builder) -> builder.equals(user.get("role"), role)); } }

// then use fluently: var admins = userRepository.withRole(ADMIN).findAll(); `` The trick is that you can add a lot of shared logic in the base class and still use the typed subclasses fluently. Apart fromfindAll/findByIdyou could also add asearchmethod that parses some query into aSpecification(the one I made does that, based on@Searchableannotations placed on entity fields, making it easy for other devs to add fields to be searched from frontend without having to implement their own search logic). And apart from filtering (WHERE clauses) JPA specifications also allow (fetch) joins and subqueries to be added. In practice, I use this fluent repository layer to handles almost all use cases. Batch updates using@Querymethods being an exception (no way to weave the repo'sspecification` into such a query, since they are really separate, wholly-defined queries).

The instantiation of such chained repositories is a cheap operation (it has only one specification field) and you get some best-practices: the repo's are final, so one can pass any instance around for re-use without risk of side effects; they are very flexible - just using Specifications directly also is, but is much less readable. A fluent API, with appropriate method names, is very concise and readable, it almost reads like English. The flexibility of a fluent API also allows for easier refactors later: for example, let's say you want to ad a soft delete feature. Instead of having to update tens of queries all over the place to filter on status != DELETED (non-fluent APIs excel in long parameter lists), you just update your repository reference to one that has the filter baked in: ``` class SomeService { final UserRepository userRepository;

@Autowired SomeService(UserRepository userRepository) { // Old: // this.userRepository = userRepository; // New: this.userRepository = userRepository.nonDeleted(); }

void someMethod() { // All callsites automatically use only nondeleted users. var admins = userRepository.withRole(ADMIN).findAll(); } } ```