JDK-6479372 : Add self types (type of 'this' aka ThisClass) to the language
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 6
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux,windows_xp
  • CPU: x86
  • Submitted: 2006-10-06
  • Updated: 2018-12-09
  • Resolved: 2011-10-31
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
The SelfType pattern (which goes by many names, and is closely related to the problem described in closed bug 6431633), in concept, is extremely useful for more sophisticated applications of generics.

The SelfType pattern in reality is a limited workaround for situations requiring the use the type of THIS class in the class definition. It takes the familiar form...

abstract class AbstractClass<THIS extends AbstractClass<THIS>> {
    abstract public THIS getThis();
    public void setPeer(THIS peer) {_peer = peer;}
    private THIS _peer;

class ConcreteClass extends AbstractClass<ConcreteClass> {
    public ConcreteClass getThis() {return this;}

Unfortunately, concrete classes, such as ConcreteClass cannot be extended with "this-awareness". Thus...

class ConcreteSubClass extends ConcreteClass {}

   ConcreteClass obj = new ConcreteClass();
   ConcreteSubClass subobj = new ConcreteSubClass();

    subobj.setPeer(obj); // !!!should be an error, but thisness is lost

The problem becomes even worse if you want two this-aware generic classes that mutually reference one another...

public abstract class AbstractPeer<THIS extends AbstractPeer<THIS,THAT>,
THAT extends AbstractPeer<THAT,THIS>> {
	public void setPeer(THAT peer) {
		_peer = peer; // this references that
		_peer.setPeer(getThis()); // that references this
	public THAT getPeer() {
		return _peer;
	public abstract THIS getThis();
	private THAT _peer;

public class AlphaPeer<THAT extends BetaPeer<AlphaPeer<THAT>>>
extends AbstractPeer<AlphaPeer<THAT>,THAT> { // !!!does not compile
	public AlphaPeer<THAT> getThis() {
		return this;

public class BetaPeer<THAT extends AlphaPeer<BetaPeer<THAT>>>
extends AbstractPeer<BetaPeer<THAT>,THAT> { // !!!does not compile
	public BetaPeer<THAT> getThis() {
		return this;

Imagine if  the java language spec were to say that a concrete class could only be extended once.  Without some inherent support for a THIS type, that is essentially what is happening (and a lot more) in more sophisticated attempts at employing generics for code reusability.

A robust this-awareness in generic classes, where concrete classes can be correctly extended, and where mutual references can be properly defined
A wimpy this-awareness in generic classes, which relies on generic constructs approaching the level of hieroglyphics (Foo<THIS extends Foo<THIS>)

The full citation for the Bruce & Foster paper is as follows: Kim B. Bruce and J. Nathan Foster. LOOJ: Weaving LOOM into Java. In European Conference on Object-Oriented Programming (ECOOP), Oslo, Norway, volume 3086 of Lecture Notes in Computer Science, pages 389--413. Springer-Verlag, June 2004. The conference paper is available here (gzipped PDF file): http://www.cs.pomona.edu/~kim/ftp/LOOJ.pdf.gz A slide presentation by one of the authors is available here: http://www.cs.cornell.edu/~jnfoster/papers/looj-slides.pdf

EVALUATION Proposals for new features in the Java programming language are no longer being accepted or maintained in the bug database at http://bugs.sun.com/. This also applies to proposals for new features in the Java Virtual Machine (that is, in the abstract JVM, as opposed to a JVM implementation like HotSpot). All proposals for new features should be made through the "JDK Enhancement - Proposal & Roadmap Process" described at http://openjdk.java.net/jeps/1. Consequently, this specific request to change the Java programming language will not be considered further. The bug database continues to accept and maintain submissions about technical errors in the design and specification of the Java programming language and the Java Virtual Machine.

EVALUATION Kim Bruce and Nate Foster have studied this extensively: http://www.cis.upenn.edu/~jnfoster/papers/looj.pdf ThisClass/ThisType is useful for any binary method, not just "more sophisticated applications of generics" as in the Description.

EVALUATION Other languages, notably Strongtalk (http://www.strongtalk.org/), have used self types. To type check any Smalltalk variant, the this type is essential. However, it does not come without restrictions, for example, it can only be used in covariant places (return types as in the above example, not method parameter types). If self types were added to the language, it would be natural to consider the return type of clone. However, changing the return type of clone to use a self type would not be compatible with existing applications and likely to cause a lot of problems. In general, the impact on the rest of the language from adding self type is likely to be just as big as adding generic types. Contrary to Strongtalk, the use in Java would be limited and covariant return types can be used to solve most of the problems that can be solved with self types. So it is not likely that we will see self types in the Java programming language.

EVALUATION I think the submitter is looking for something like this: class Foo { protected this clone() { return (this) super.clone(); } }