What Does it Mean to Pass a Generic Class Itself as a Parameter?

[KevinSimonson]

I'm currently taking a class pretty much each week to prepare for the
SCJP exam. In the classes we usually go over practice exams and try
to figure out what the right answer is to a number of the questions.
After the chapter on Generics, one of the questions involved a class
like the one I call {Wierd} here. It was kind of of the form:

public class Wierd< T extends Wierd>
{
public Wierd ()
{
}
}

and then we had a class of the form:

public class Hmm
{
public static void main ( String[] arguments)
{
Wierd< Wierd> wow = new Wierd< Wierd>();
}
}

Can anyone tell me what's going on here? In {Wierd} itself is the
{Wierd} that's being extended in the angle brackets the same {Wierd}
that's being defined in this file? And what exactly is happening in
{main()} when I declare {wow} to be a {Wierd< Wierd>} object? I'd
really appreciate it if someone could explain this to me.

Kevin Simonson

 

[Jeff Higgins]

public class Wierd< T extends Wierd>
{
public Wierd ()
{
}
}

If you mean
class Foo< T extends Foo<T>>
you can search
java+generics+recursive+bounds
or
<http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#FAQ206>

 

[markspace]

Can anyone tell me what's going on here? In {Wierd} itself is the
{Wierd} that's being extended in the angle brackets the same {Wierd}
that's being defined in this file?

Yes. Extension, and polymorphism, just mean "type." Weird is a type of
Weird, so it fulfills the bound that the type of T must be a type of
Weird (extends Weird).

And what exactly is happening in
{main()} when I declare {wow} to be a {Wierd< Wierd>} object?

Well, you didn't do anything with the type parameter T, so not a lot is
happening. Try to find some existing classes that use type parameters,
like the Collections classes, and ask that question for them.

 

[Jeff Higgins]

If you mean
class Foo< T extends Foo<T>>
you can search
java+generics+recursive+bounds
or
<http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#FAQ206>

or
<http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#FAQ106>

 

[Screamin Lord Byron]

I'm currently taking a class pretty much each week to prepare for the
SCJP exam. In the classes we usually go over practice exams and try
to figure out what the right answer is to a number of the questions.
After the chapter on Generics, one of the questions involved a class
like the one I call {Wierd} here. It was kind of of the form:

public class Wierd< T extends Wierd>
{
public Wierd ()
{
}
}

and then we had a class of the form:

public class Hmm
{
public static void main ( String[] arguments)
{
Wierd< Wierd> wow = new Wierd< Wierd>();
}
}

Can anyone tell me what's going on here? In {Wierd} itself is the
{Wierd} that's being extended in the angle brackets the same {Wierd}
that's being defined in this file?

It just means that the type parameter must fulfill an IS-A relation with
Wierd. It must be Wierd or any subclass of Wierd. That's it. Nothing is
being extended here.

And what exactly is happening in
{main()} when I declare {wow} to be a {Wierd< Wierd>} object? I'd
really appreciate it if someone could explain this to me.

Nothing special is happening. You just instantiate the object of a class
Wierd. From JVM's point of view it is exactly the same as:
Wierd wow = new Wierd();

 

[Lew]

On a tangential note, it's best practice to make identifiers, such as your class name 'Wierd', either sufficiently obviously not intended to be a natural-language word that spelling is not an issue, or to spell it the same asthe natural-language word it resembles. So, for example, to model a boundary, 'bnd' would be an acceptable variable name, but 'boundray' would not be. The reason is that it's too difficult for maintainers to get near-miss spelling correct - the pull to spell the variable or type name the same as the natural-language word is just too strong.

So fix the spelling of 'Wierd'.

 

[Daniel Pitts]

On a tangential note, it's best practice to make identifiers, such as your class name 'Wierd', either sufficiently obviously not intended to be a natural-language word that spelling is not an issue, or to spell it the same as the natural-language word it resembles. So, for example, to model a boundary, 'bnd' would be an acceptable variable name, but 'boundray' would not be. The reason is that it's too difficult for maintainers to get near-miss spelling correct - the pull to spell the variable or type name the same as the natural-language word is just too strong.

So fix the spelling of 'Wierd'.

Weird, IntelliJ IDEA will not only auto-suggest the correctly misspelled
variant, but the latest version, with the Spell Correct plug in, will
offer to rename the symbol in question to the correct spelling, taking
into account Camel Case word boundaries and all.

Wow, talk about a run-on sentence. Oh well, the point is that tools are
cool and help us flawed humans recover from many common mistakes.

 

[Jeff Higgins]

Wow, talk about a run-on sentence. Oh well, the point is that tools are
cool and help us flawed humans recover from many common mistakes.

Hammer with built-in nail puller. How cool is that?

 

[Lew]

Weird, IntelliJ IDEA will not only auto-suggest the correctly misspelled
variant, but the latest version, with the Spell Correct plug in, will
offer to rename the symbol in question to the correct spelling, taking
into account Camel Case word boundaries and all.

Wow, talk about a run-on sentence. Oh well, the point is that tools are
cool and help us flawed humans recover from many common mistakes.

Tools can help one be more diligent; they cannot make one be diligent.

IntelliJ wouldn't have that feature were it not a best practice to spell identifiers intelligibly.

The programmer still has to be aware that there is such a best practice, and to follow it.

 

[Jeff Higgins]

On 10/10/2011 11:01 AM, KevinSimonson wrote:

also
public class Foo< T extends Foo>
{
public Foo () {}

public static void main ( String[] arguments)
{
Foo< Foo> bar = new Foo< Foo>();
}

/*
Depending upon what you have between these curly braces
mixing the raw type Foo with the parameterized type
Foo<T extends Foo> might not produce fubar.
*/

}