I have an assignment in my Java class, we are learning Generics, I have looked in my notes, my lessons, and even on the internet and I still cant figure out what this last assignment question is asking me to do, which is:
Write a generic “greater-than” function that takes two objects as arguments, each of which has a “value” method which returns an integer and returns the argument whose “value” method returns the larger integer. Your generic function should constrain its type argument so that types without a “value” method cannot be used.
Is there a reason why "value" in quotation marks and how can a method constrain its type argument so that types without a "value" method cant be used. I'm mainly asking for clarification or maybe a little example.
Am I creating a Value class and then doing something like this:
public static <T> int greaterThan(Value obj1, Value obj2){ // Value will have the "value" method?
// do I compare the objects here or in the Value class?
}
They are apparently asking you to implement a generic maxByValue method. Since greater-than contains a hyphen, and is thus an invalid Java identifier anyway, I'll stick to maxByValue.
The requirement of having a value method is mentioned a few times, so let's encode it as an interface:
interface Value {
int value();
}
Now, the main point of having a generic parameter here is to make sure that the return type of the maxByValue is specific enough to be useful. Let's call this type T. In order for the arguments to be comparable, T must be a subtype of Value. The only meaningful source for obtaining the return type is from the types of arguments. Putting together the three points:
Type parameter T subtype Value
Type inferred from the arguments
Result type is T
gives you the signature:
public static <T extends Value> T maxByValue(T a, T b)
There are basically just two meaningful ways of implementing this. Let's take the left-biased one (i.e. left argument is returned if value is the same):
public static <T extends Value> T maxByValue(T a, T b) {
if (a.value() < b.value()) {
return b;
} else {
return /* left as an exercise */;
}
}
Let's try it on a trivial integer example:
class IntValue implements Value {
final int v;
public IntValue(int v) {
this.v = v;
}
public int value() {
return v;
}
#Override
public String toString() {
return "" + v;
}
}
IntValue a = new IntValue(42);
IntValue b = new IntValue(58);
IntValue c = max(a, b);
System.out.println(c); // prints "58"
So far so good. Let's see how precise the type inference is:
static interface Vehicle extends Value {
String doGenericVehicleSound();
}
static abstract class Car implements Vehicle {
public abstract String doCarSpecificSound();
public String doGenericVehicleSound() {
return doCarSpecificSound();
}
}
static class Train implements Vehicle {
public String doGenericVehicleSound() {
return "tk-tk-------tk-tk--tk-tk--------------tk-tk";
}
public int value() {
return 10000000;
}
}
static class Ferrari extends Car {
public String doCarSpecificSound() {
return "rr-rrr-rrrr-rrrrrrr-rrrrrrrrrrrrrrrrrrrr-RRRRRRRRRR";
}
public int value() {
return 222000;
}
}
static class Tesla extends Car {
public String doCarSpecificSound() {
return "... ... ¯\\_(ツ)_/¯";
}
public int value() {
return 50000;
}
}
public static void main(String []args){
System.out.println(maxByValue(new Ferrari(), new Tesla()).doCarSpecificSound());
System.out.println(maxByValue(new Tesla(), new Train()).doGenericVehicleSound());
// System.out.println(maxByValue(new Tesla(), new Train()).doCarSpecificSound());
}
The point to see here is the following. We have the following subtyping relation:
Train extends Vehicle
Car extends Vehicle
Ferrari extends Car
Tesla extends Car
and the following least upper bounds for the concrete instances:
LUB(Train, Train) = Train
LUB(Train, Ferrari) = Vehicle
LUB(Train, Tesla) = Vehicle
LUB(Ferrari, Ferrari) = Ferrari
LUB(Ferrari, Tesla) = Car
LUB(Tesla, Tesla) = Tesla
(and all symmetric cases too).
Now, when we
put two cars into maxByValue, we get out a car (first example), but
when we put a car and a train into maxByValue, we get a more general Vehicle,
so that the car-specific methods become unavailable (examples two and three; third does not compile - rightly so, because a train has no car-methods).
Let's define the interface with value() method
and provide default implementation of isGreaterThan
We could make this interface generic (to work with the types bounded to HasValue)
public interface HasValue<T extends HasValue<T>> {
int value();
default boolean isGreaterThan(T that) {
return this.value() > that.value();
}
}
Now generic methods should be upper-bound T extends HasValue:
static <T extends HasValue> boolean isGreaterThanGeneric(T arg1, T arg2) {
return arg1.value() > arg2.value();
}
static <T extends HasValue> T getGreaterGeneric(T arg1, T arg2) {
return arg1.isGreaterThan(arg2) ? arg1 : arg2;
}
Let's provide some test implementations of HasValue interface and test them.
Note: implementations should be bound HasValue<MyClass> to restrict the interface to be applied to the same type (thanks #Kayaman)
class Apple implements HasValue<Apple> {
final String type;
Apple(String t) {
this.type = t;
}
#Override
public int value() { return 10; }
#Override
public String toString() {
return "apple " + type;
}
}
class Orange implements HasValue<Orange> {
#Override
public int value() { return 20; }
#Override
public String toString() {
return "orange";
}
}
Test:
public static void main(String args[]) {
Apple apple = new Apple("Golden");
Apple apple1 = new Apple("Jonagold");
Orange orange = new Orange();
System.out.println("apple greater than orange = " + getGreater(apple, orange));
System.out.println("apple greater than another apple generic = " + getGreaterGeneric(apple, apple1));
// System.out.println("apple greater than orange generic = " + getGreaterGeneric(apple, orange)); // <-- won't compile:
// required: T,T
// found: Apple,Orange
// reason: inference variable T has incompatible bounds
}
Output:
apple greater than orange = orange
apple greater than another apple generic = apple Jonagold
The previous example is a little complex, but all you're doing is binding your generic value so that it won't accept something that doesn't compile.
With your code...
public static <T> int greaterThan(Value obj1, Value obj2){ }
...the generic here is useless since you only ever use Value objects. This might incidentally work because if you have a FooValue extends Value object, because FooValue is-a Value, it'd be seen as a valid parameter here.
(Note: this is how Java pre-generics was done: inheritance.)
What you're probably looking for is this instead:
public static <T extends Value> int greaterThan(T obj1, T obj2) { }
This is a bound such that the generic type T is bound to all values that are Value and its subclasses.
Related
Here is a minimal code example. The interface:
interface Individual<T> {
public T getVariableValue(int index) ;
public void setVariableValue(int index, T value) ;
public int getNumberOfVariables() ;
public int getNumberOfObjectives() ;
public Individual<T> copy() ;
}
And the class:
public class minimalExample<S extends Individual> {
private List<S> doCrossover(List<S> s){
S mom = s.get(0);
S dad = s.get(1);
int crossoverPoint = 5;
S girl = mom.copy();
S boy = dad.copy();
for (int i = 0; i < mom.getNumberOfVariables(); i++) {
if(i > crossoverPoint){
boy.setVariableValue(i, mom.getVariableValue(i));
girl.setVariableValue(i,dad.getVariableValue(i));
}
}
return s;
}
}
If i try to compile this i get:
java: incompatible types: Individual cannot be converted to S
Which seems confusing. Doesn' the extends keyword mean that S has to be of type Individual or a subtype?
Which seems confusing. Doesn' the extends keyword mean that S has to be of type Individual or a subtype?
Yes, but that does not mean that the type returned by an S's copy() method is also an S. The Individual interface requires only that it be an Individual.
Moreover, I observe that your class minimalExample is using the raw type Individual, whereas it ought to use a properly parameterized version (or else Individual should be made non-generic).
You may be over-parameterizing here. Does minimalExample really need to use S instead of directly using Individual? Obviously, this example class does not, but perhaps the one that inspired the question doesn't, either.
On the other hand, if you do need a parameter for the specific type of Individual, then perhaps you need to further parameterize that interface to describe the kind of object its copy() method returns:
interface Individual<T,I extends Individual<T, I>> {
public T getVariableValue(int index) ;
public void setVariableValue(int index, T value) ;
public int getNumberOfVariables() ;
public int getNumberOfObjectives() ;
public I copy() ;
}
You could then declare your class MinimalExample with the needed additional information:
public class MinimalExample<T, S extends Individual<T, S>> {
// ...
}
And here is a dummy implementation of Individual that you could use with that:
public class ExampleIndividual<T> implements Individual<T, ExampleIndividual<T>> {
public T getVariableValue(int index) { return null; }
public void setVariableValue(int index, T value) {}
public int getNumberOfVariables() { return 0; }
public int getNumberOfObjectives() { return 0; }
public ExampleIndividual<T> copy() { return new ExampleIndividual<T>(); }
}
The method copy() returns an object of type "Individual", which cannot be assigned to the type "S" since S is a subtype.
Why are girl and boy declared to be of type "S" and not Individual?
I know I can check whether a String is contained in a specific Enum using the concept described by pseudo code below(I know there's no contains method for Enum, that's just for my example) :
Enum Animal {
Dog,
Cat,
Human
}
public boolean CheckAnimalValid(String name){
return Animal.contains(name)? true : false;
}
But in previous way I need to implement the CheckValid method for each Enum class, since I need to know WHICH Enum class should I to check.
I want to know is there any method to pass Enum type as a parameter to a function, so that I can do in this way:
Enum Animal {
Dog,
Cat,
Person
}
Enum Plant {
Grass,
Flower,
Tree
}
public boolean CheckEnumValid(String name, what_should_I_do? enum){
return enum.contains(name)? true : false;
}
I want to know which type(or keyword) should I use in what_should_I_do? in the previous code. I know I should use Generics, but I don't know how to do. Thanks!
You can use the static method Enum.valueOf(Class<T> enumType, String name) which returns an enum of type T, if the name matches an enum constants of that type. Otherwise is throws an IllegalArgumentException.
Example usage:
Enum.valueOf(Plant.class, "Flower");
Wrapped in a method that returns a boolean:
public <T extends Enum<T>> boolean checkValid(Class<T> enumType, String name){
try {
Enum.valueOf(enumType, name);
return true;
} catch(IllegalArgumentException e) {
return false;
}
}
Not certain if I fully understand your need but I suspect you want to lookuup in any enum by String - if that is the case then there are several ways to do this.
First - let's define what you are looking for - something like this?
interface Lookup<S,T> {
T lookup(S s);
}
Now you could adjust every enum to do something like this:
enum Animal implements Lookup<String,Animal>{
Dog,
Cat,
Person;
Map<String,Animal> lookup = Arrays.stream(Animal.values())
.collect(Collectors.toMap(e -> e.name(), e -> e));
public Animal lookup(String name) {
return lookup.get(name);
}
}
But I suspect you want to do this without hacking all of your enums - which would be a pain. Here's one method using a helper object.
class EnumLookup<E extends Enum<E>> implements Lookup<String,E> {
final Map<String,E> lookup;
public EnumLookup(Class<E> clazz) {
lookup = Arrays.stream(clazz.getEnumConstants())
.collect(Collectors.toMap(e -> e.name(), e -> e));
}
#Override
public E lookup(String s) {
return lookup.get(s);
}
}
Now you can create one of these to interrogate the enum whenever you like.
enum Plant {
Grass,
Flower,
Tree;
}
public void test() {
EnumLookup<Plant> lookup = new EnumLookup<>(Plant.class);
System.out.println("Tree -> "+lookup.lookup("Tree"));
}
It would be nice if you implement a generic method instead, java allows using contrains so you can for sure PASS ONLY AN ENUM, and thanks to interfaces you can restrict at compiling time what enums are allowed or not:
Define this generic method
public <T extends Enum<?> & ITag> void printEnum(T d) {
System.out.println(d.name());
}
define a tag interface:
interface ITag {
}
now you can Tag the enums that only valid in the method:
enum Color implements ITag {
RED, GREEN, BLUE
}
enum STATE {
ON, OFF
}
enum CONNECTION {
UDP, TCP
}
as result, you can check if a method is taking the correct param at compiling time...
printEnum(Color.GREEN); //valid
printEnum(STATE.OFF);// invalid The method printEnum(T)... is not applicable for the arguments..
printEnum(CONNECTION.UDP);// invalid The method printEnum(T)... is not applicable for the arguments..
printEnum("Green"); // invalid The method printEnum(T)... is not applicable for the arguments..
I thought I understood Java generics pretty well, but then I came across the following in java.lang.Enum:
class Enum<E extends Enum<E>>
Could someone explain how to interpret this type parameter? Bonus points for providing other examples of where a similar type parameter could be used.
It means that the type argument for enum has to derive from an enum which itself has the same type argument. How can this happen? By making the type argument the new type itself. So if I've got an enum called StatusCode, it would be equivalent to:
public class StatusCode extends Enum<StatusCode>
Now if you check the constraints, we've got Enum<StatusCode> - so E=StatusCode. Let's check: does E extend Enum<StatusCode>? Yes! We're okay.
You may well be asking yourself what the point of this is :) Well, it means that the API for Enum can refer to itself - for instance, being able to say that Enum<E> implements Comparable<E>. The base class is able to do the comparisons (in the case of enums) but it can make sure that it only compares the right kind of enums with each other. (EDIT: Well, nearly - see the edit at the bottom.)
I've used something similar in my C# port of ProtocolBuffers. There are "messages" (immutable) and "builders" (mutable, used to build a message) - and they come as pairs of types. The interfaces involved are:
public interface IBuilder<TMessage, TBuilder>
where TMessage : IMessage<TMessage, TBuilder>
where TBuilder : IBuilder<TMessage, TBuilder>
public interface IMessage<TMessage, TBuilder>
where TMessage : IMessage<TMessage, TBuilder>
where TBuilder : IBuilder<TMessage, TBuilder>
This means that from a message you can get an appropriate builder (e.g. to take a copy of a message and change some bits) and from a builder you can get an appropriate message when you've finished building it. It's a good job users of the API don't need to actually care about this though - it's horrendously complicated, and took several iterations to get to where it is.
EDIT: Note that this doesn't stop you from creating odd types which use a type argument which itself is okay, but which isn't the same type. The purpose is to give benefits in the right case rather than protect you from the wrong case.
So if Enum weren't handled "specially" in Java anyway, you could (as noted in comments) create the following types:
public class First extends Enum<First> {}
public class Second extends Enum<First> {}
Second would implement Comparable<First> rather than Comparable<Second>... but First itself would be fine.
The following is a modified version of the explanation from the book Java Generics and Collections:
We have an Enum declared
enum Season { WINTER, SPRING, SUMMER, FALL }
which will be expanded to a class
final class Season extends ...
where ... is to be the somehow-parameterised base class for Enums. Let's work
out what that has to be. Well, one of the requirements for Season is that it should implement Comparable<Season>. So we're going to need
Season extends ... implements Comparable<Season>
What could you use for ... that would allow this to work? Given that it has to be a parameterisation of Enum, the only choice is Enum<Season>, so that you can have:
Season extends Enum<Season>
Enum<Season> implements Comparable<Season>
So Enum is parameterised on types like Season. Abstract from Season and
you get that the parameter of Enum is any type that satisfies
E extends Enum<E>
Maurice Naftalin (co-author, Java Generics and Collections)
This can be illustrated by a simple example and a technique which can be used to implement chained method calls for sub-classes. In an example below setName returns a Node so chaining won't work for the City:
class Node {
String name;
Node setName(String name) {
this.name = name;
return this;
}
}
class City extends Node {
int square;
City setSquare(int square) {
this.square = square;
return this;
}
}
public static void main(String[] args) {
City city = new City()
.setName("LA")
.setSquare(100); // won't compile, setName() returns Node
}
So we could reference a sub-class in a generic declaration, so that the City now returns the correct type:
abstract class Node<SELF extends Node<SELF>>{
String name;
SELF setName(String name) {
this.name = name;
return self();
}
protected abstract SELF self();
}
class City extends Node<City> {
int square;
City setSquare(int square) {
this.square = square;
return self();
}
#Override
protected City self() {
return this;
}
public static void main(String[] args) {
City city = new City()
.setName("LA")
.setSquare(100); // ok!
}
}
You are not the only one wondering what that means; see Chaotic Java blog.
“If a class extends this class, it should pass a parameter E. The parameter E’s bounds are for a class which extends this class with the same parameter E”.
This post has totally clarified to me these problem of 'recursive generic types'.
I just wanted to add another case where this particular structure is necessary.
Suppose you have generic nodes in a generic graph:
public abstract class Node<T extends Node<T>>
{
public void addNeighbor(T);
public void addNeighbors(Collection<? extends T> nodes);
public Collection<T> getNeighbor();
}
Then you can have graphs of specialized types:
public class City extends Node<City>
{
public void addNeighbor(City){...}
public void addNeighbors(Collection<? extends City> nodes){...}
public Collection<City> getNeighbor(){...}
}
If you look at the Enum source code, it has the following:
public abstract class Enum<E extends Enum<E>>
implements Comparable<E>, Serializable {
public final int compareTo(E o) {
Enum<?> other = (Enum<?>)o;
Enum<E> self = this;
if (self.getClass() != other.getClass() && // optimization
self.getDeclaringClass() != other.getDeclaringClass())
throw new ClassCastException();
return self.ordinal - other.ordinal;
}
#SuppressWarnings("unchecked")
public final Class<E> getDeclaringClass() {
Class<?> clazz = getClass();
Class<?> zuper = clazz.getSuperclass();
return (zuper == Enum.class) ? (Class<E>)clazz : (Class<E>)zuper;
}
public static <T extends Enum<T>> T valueOf(Class<T> enumType,
String name) {
T result = enumType.enumConstantDirectory().get(name);
if (result != null)
return result;
if (name == null)
throw new NullPointerException("Name is null");
throw new IllegalArgumentException(
"No enum constant " + enumType.getCanonicalName() + "." + name);
}
}
First thing first, what does E extends Enum<E> mean? It means the type parameter is something that extends from Enum, and isn't parametrized with a raw type (it's parametrized by itself).
This is relevant if you have an enum
public enum MyEnum {
THING1,
THING2;
}
which, if I know correctly, is translated to
public final class MyEnum extends Enum<MyEnum> {
public static final MyEnum THING1 = new MyEnum();
public static final MyEnum THING2 = new MyEnum();
}
So this means that MyEnum receives the following methods:
public final int compareTo(MyEnum o) {
Enum<?> other = (Enum<?>)o;
Enum<MyEnum> self = this;
if (self.getClass() != other.getClass() && // optimization
self.getDeclaringClass() != other.getDeclaringClass())
throw new ClassCastException();
return self.ordinal - other.ordinal;
}
And even more importantly,
#SuppressWarnings("unchecked")
public final Class<MyEnum> getDeclaringClass() {
Class<?> clazz = getClass();
Class<?> zuper = clazz.getSuperclass();
return (zuper == Enum.class) ? (Class<MyEnum>)clazz : (Class<MyEnum>)zuper;
}
This makes getDeclaringClass() cast to the proper Class<T> object.
A way clearer example is the one that I answered on this question where you cannot avoid this construct if you want to specify a generic bound.
According to wikipedia, this pattern is called Curiously recurring template pattern.
Basically, by using the CRTP pattern, we can easily refer to subclass type without type casting, which means by using the pattern, we can imitate virtual function.
I have in mind an interface which declares a method for converting a raw score from a survey to a percentile value for a particular category, where the categories are described by more than one otherwise unrelated enum types. So I started with this:
public interface NormTable<E extends Enum<E>> {
Integer percentileForRawScore(E e, int score);
}
I've then got an implementing class for, say, the Foo survey and its Subscale enum:
public class FooSubscaleNormTable implements NormTable<Subscale> {
public Integer percentileForRawScore(Subscale e, int score) {
// Implementation
}
}
And finally, a factory class for creating the appropriate concrete class:
public class NormTableFactory {
public static <E extends Enum<E>> NormTable<E> normTableForSurveyAndType(
String surveyCode, Class<E> clazz) {
if ("Foo".equals(surveyCode) && Subscale.class.equals(clazz)) {
return (NormTable<E>) new FooSubscaleNormTable();
} else {
// ...
}
}
}
I suspect the cast there is wrong, as Eclipse flags it as unchecked, though lets me carry on. The Java 1.6 compiler on the build server, however, is not happy at all and flags them as inconvertible types.
Have I got the signatures in the factory class wrong, or is my whole architecture looking suspect? I note above that the enum types are "otherwise unrelated", though they all represent categories within surveys, and could conceivably implement an interface to unify their types. Would that help?
You shouldn't use a concrete Enum class in your declaring type.
Make FooSubscaleNormTable generic as well
public class FooSubscaleNormTable<E extends Enum<E>> implements NormTable<E> {
public Integer percentileForRawScore(E e, int score) {
if(e instanceof Subscale) {
switch((Subscale) e) {
case X:
// do something
break;
}
}
// return 0;
}
}
and change your factory to
public class NormTableFactory {
public static <E extends Enum<E>> NormTable<E> normTableForSurveyAndType(
String surveyCode, Class<E> clazz) {
if ("Foo".equals(surveyCode) && Subscale.class.equals(clazz)) {
return (NormTable<E>) new FooSubscaleNormTable<E>();
} else {
// whatever else
}
}
}
Then when you invoke it, that is when you pass in your desired enum type.
NormTable<Subscale> scale = NormTableFactory.normTableForSurveyAndType("surveyCode", Subscale.class);
I thought I understood Java generics pretty well, but then I came across the following in java.lang.Enum:
class Enum<E extends Enum<E>>
Could someone explain how to interpret this type parameter? Bonus points for providing other examples of where a similar type parameter could be used.
It means that the type argument for enum has to derive from an enum which itself has the same type argument. How can this happen? By making the type argument the new type itself. So if I've got an enum called StatusCode, it would be equivalent to:
public class StatusCode extends Enum<StatusCode>
Now if you check the constraints, we've got Enum<StatusCode> - so E=StatusCode. Let's check: does E extend Enum<StatusCode>? Yes! We're okay.
You may well be asking yourself what the point of this is :) Well, it means that the API for Enum can refer to itself - for instance, being able to say that Enum<E> implements Comparable<E>. The base class is able to do the comparisons (in the case of enums) but it can make sure that it only compares the right kind of enums with each other. (EDIT: Well, nearly - see the edit at the bottom.)
I've used something similar in my C# port of ProtocolBuffers. There are "messages" (immutable) and "builders" (mutable, used to build a message) - and they come as pairs of types. The interfaces involved are:
public interface IBuilder<TMessage, TBuilder>
where TMessage : IMessage<TMessage, TBuilder>
where TBuilder : IBuilder<TMessage, TBuilder>
public interface IMessage<TMessage, TBuilder>
where TMessage : IMessage<TMessage, TBuilder>
where TBuilder : IBuilder<TMessage, TBuilder>
This means that from a message you can get an appropriate builder (e.g. to take a copy of a message and change some bits) and from a builder you can get an appropriate message when you've finished building it. It's a good job users of the API don't need to actually care about this though - it's horrendously complicated, and took several iterations to get to where it is.
EDIT: Note that this doesn't stop you from creating odd types which use a type argument which itself is okay, but which isn't the same type. The purpose is to give benefits in the right case rather than protect you from the wrong case.
So if Enum weren't handled "specially" in Java anyway, you could (as noted in comments) create the following types:
public class First extends Enum<First> {}
public class Second extends Enum<First> {}
Second would implement Comparable<First> rather than Comparable<Second>... but First itself would be fine.
The following is a modified version of the explanation from the book Java Generics and Collections:
We have an Enum declared
enum Season { WINTER, SPRING, SUMMER, FALL }
which will be expanded to a class
final class Season extends ...
where ... is to be the somehow-parameterised base class for Enums. Let's work
out what that has to be. Well, one of the requirements for Season is that it should implement Comparable<Season>. So we're going to need
Season extends ... implements Comparable<Season>
What could you use for ... that would allow this to work? Given that it has to be a parameterisation of Enum, the only choice is Enum<Season>, so that you can have:
Season extends Enum<Season>
Enum<Season> implements Comparable<Season>
So Enum is parameterised on types like Season. Abstract from Season and
you get that the parameter of Enum is any type that satisfies
E extends Enum<E>
Maurice Naftalin (co-author, Java Generics and Collections)
This can be illustrated by a simple example and a technique which can be used to implement chained method calls for sub-classes. In an example below setName returns a Node so chaining won't work for the City:
class Node {
String name;
Node setName(String name) {
this.name = name;
return this;
}
}
class City extends Node {
int square;
City setSquare(int square) {
this.square = square;
return this;
}
}
public static void main(String[] args) {
City city = new City()
.setName("LA")
.setSquare(100); // won't compile, setName() returns Node
}
So we could reference a sub-class in a generic declaration, so that the City now returns the correct type:
abstract class Node<SELF extends Node<SELF>>{
String name;
SELF setName(String name) {
this.name = name;
return self();
}
protected abstract SELF self();
}
class City extends Node<City> {
int square;
City setSquare(int square) {
this.square = square;
return self();
}
#Override
protected City self() {
return this;
}
public static void main(String[] args) {
City city = new City()
.setName("LA")
.setSquare(100); // ok!
}
}
You are not the only one wondering what that means; see Chaotic Java blog.
“If a class extends this class, it should pass a parameter E. The parameter E’s bounds are for a class which extends this class with the same parameter E”.
This post has totally clarified to me these problem of 'recursive generic types'.
I just wanted to add another case where this particular structure is necessary.
Suppose you have generic nodes in a generic graph:
public abstract class Node<T extends Node<T>>
{
public void addNeighbor(T);
public void addNeighbors(Collection<? extends T> nodes);
public Collection<T> getNeighbor();
}
Then you can have graphs of specialized types:
public class City extends Node<City>
{
public void addNeighbor(City){...}
public void addNeighbors(Collection<? extends City> nodes){...}
public Collection<City> getNeighbor(){...}
}
If you look at the Enum source code, it has the following:
public abstract class Enum<E extends Enum<E>>
implements Comparable<E>, Serializable {
public final int compareTo(E o) {
Enum<?> other = (Enum<?>)o;
Enum<E> self = this;
if (self.getClass() != other.getClass() && // optimization
self.getDeclaringClass() != other.getDeclaringClass())
throw new ClassCastException();
return self.ordinal - other.ordinal;
}
#SuppressWarnings("unchecked")
public final Class<E> getDeclaringClass() {
Class<?> clazz = getClass();
Class<?> zuper = clazz.getSuperclass();
return (zuper == Enum.class) ? (Class<E>)clazz : (Class<E>)zuper;
}
public static <T extends Enum<T>> T valueOf(Class<T> enumType,
String name) {
T result = enumType.enumConstantDirectory().get(name);
if (result != null)
return result;
if (name == null)
throw new NullPointerException("Name is null");
throw new IllegalArgumentException(
"No enum constant " + enumType.getCanonicalName() + "." + name);
}
}
First thing first, what does E extends Enum<E> mean? It means the type parameter is something that extends from Enum, and isn't parametrized with a raw type (it's parametrized by itself).
This is relevant if you have an enum
public enum MyEnum {
THING1,
THING2;
}
which, if I know correctly, is translated to
public final class MyEnum extends Enum<MyEnum> {
public static final MyEnum THING1 = new MyEnum();
public static final MyEnum THING2 = new MyEnum();
}
So this means that MyEnum receives the following methods:
public final int compareTo(MyEnum o) {
Enum<?> other = (Enum<?>)o;
Enum<MyEnum> self = this;
if (self.getClass() != other.getClass() && // optimization
self.getDeclaringClass() != other.getDeclaringClass())
throw new ClassCastException();
return self.ordinal - other.ordinal;
}
And even more importantly,
#SuppressWarnings("unchecked")
public final Class<MyEnum> getDeclaringClass() {
Class<?> clazz = getClass();
Class<?> zuper = clazz.getSuperclass();
return (zuper == Enum.class) ? (Class<MyEnum>)clazz : (Class<MyEnum>)zuper;
}
This makes getDeclaringClass() cast to the proper Class<T> object.
A way clearer example is the one that I answered on this question where you cannot avoid this construct if you want to specify a generic bound.
According to wikipedia, this pattern is called Curiously recurring template pattern.
Basically, by using the CRTP pattern, we can easily refer to subclass type without type casting, which means by using the pattern, we can imitate virtual function.