I have seen this in the Jenkins API, and I would like to understand the purpose of this pattern. I cannot grasp the meaning of JobT and RunT.
Class Run<JobT extends Job<JobT,RunT>,RunT extends Run<JobT,RunT>>
It is a somewhat complicated but reasonably common way to define two types that strongly relate to each other and always should be used in tandem.
JobT is the specific job type that both knows about itself (Job<JobT) and also knows about RunT (,RunT).
In exactly the same way the RunT can know about itself and the JobT.
This ensures that Run.getNextBuild() can always return the specific type of itself (without the RunT type it would have to return a generic Run) and that getParent() can return the specific JobT.
Without both of these parameters a code like this wouldn't work:
SomeSpecificRun myRun = ...;
SomeSpecificJob myJob = myRun.getParent();
SomeSpecificRun previousSuccessfulRun = myJob.getPreviousBuild();
Unless Job "knows of" (i.e. has a type parameter of) the run type and Run "knows of" (i.e. has a type parameter of) the job type, this could couldn't reference the specific Run/Job classes and would quickly devolve into manual casts to the specific class.