&gt; I don&#x27;t know what you mean by &quot;fully exploit&quot;,<p>If the return type of one of your overloads is itself a generic type, you can&#x27;t represent that in the type of the method. Consider the IntBoolFactory from the paper, and then add two operations for lambda abstraction and function application:<p><pre><code>    public Exp lambda(Exp=&gt;Exp body);
    public Exp apply(Exp lambda, Exp arg);
</code></pre>
Where Exp=&gt;Exp represents a Java lambda taking an Exp and returnin an Exp. Notice how the type of the lambda and its argument must now be dynamically type checked to ensure that &#x27;arg&#x27; has the same type as the parameter for the lambda. With higher kinded types, you could write something like this instead:<p><pre><code>    public &lt;T0, T1&gt; Exp lambda(Exp&lt;T0&gt;=&gt;Exp&lt;T1&gt; body);
    public &lt;T0, T1&gt; Exp&lt;T1&gt; apply(Exp&lt;T0,T1&gt; lambda, Exp&lt;T0&gt; arg);
</code></pre>
And now everything is statically type checked by the Java compiler. Without higher kinded types, you gain extensibility in every direction using object algebras, but you lose some type checking.