I need to define a generic class, and the type parameter must be an enum. I think it should look something like
public class <T> MyClass<T extends Enum<T>> {
}
But I can't seem to figure out the exact syntax. I should mention that I need a way to refer to the type (within MyClass) that it is instantiated with.
Thanks!
public class MyClass<T extends Enum<T>> { }
While the approved answer looks syntactically correct, what's the scenario for such a declaration? Are you trying to write some class that can operate on any enum-defined type, like java.util.EnumSet or java.util.EnumMap? It's an unusual arrangement, so be sure you really need it in order to meet your requirements.
Related
Notation: Inter is interface; Abs[N] is an abstract class.
The following code works fine in Java without a problem:
public class Impl<T extends Abs1<T>> extends Abs2<T> {...}
However, if you want to introduce another bound by an interface on T, I haven't found any easy way to do it, namely:
public class Impl<T extends Inter & Abs1<T>> extends Abs2<T> {...}
won't work because Abs1 as an abstract class cannot be used as a bounding parameter. The simplest, but ugly (is it ugly?) solution I have found is:
public class Impl<B extends Inter, T extends Abs1<B>> extends Abs2<T> {...}
I have a hunch that in Scala with the traits there exists a more elegant solution, but are there any tips for Java?
Oh my... well, this is embarrassing. I was so focused on the F-Bound, that I forgot that this comes directly from the JLS, section 4.4:
Every type variable declared as a type parameter has a bound. If no bound is declared for a type variable, Object is assumed. If a bound is declared, it consists of either:
a single type variable T, or
a class or interface type T possibly followed by interface types I1 & ... & In.
In other words the (abstract) class declaration must come first in an intersection type. The described behaviour has nothing to do with F-Boundedness. I.e., the following works:
public class Impl<T extends Abs1<T> & Inter> extends Abs2<T> {...}
This is also described in the Java Tutorial. If one thinks about it, it is self-explanatory, hence this way the parser has an easy way to check for double-inheritance (which is prohibited).
I just stumbled with a situation I think I have not tried before.
I have this:
class A<DATA>
class B extends A<SomeSpecificDataClass>
Now, I want to declare a third class like this:
class C <T extends A<DATA>{
public someMethod(T instance, DATA data){}
}
I know I could just ask the instance for its data, but for the API I'm building, I'd REALLY prefer to have a syntax like this. Any ideas how to do it?
Thanks in advance.
Since DATA would be another generic, then you should declare that the class uses two generics:
class C<DATA, T> {
}
Then, you could define other requirements for T based on DATA:
class C<DATA, T extends A<DATA>> {
}
Is there is any actual difference between these this generic
public class SelfBounded <T extends SelfBounded<T>>{}
and this one
public class SelfBounded <T extends SelfBounded>{}
?
If yes, then how can I observe them?
There are a lot of similar questions here already.
You can read the following article
Or the following questions:
Java Enum definition
Why in java enum is declared as Enum<E extends Enum<E>>
What would be different in Java if Enum declaration didn't have the recursive part
The second one uses a raw type, which should never be used.
But actually neither of these declarations are normally useful. You should almost certainly just use
public class SelfBounded <T>
Has this interface:
public interface Cloneable<T>
{
public T clone();
}
And it's implementing class:
public class Clazz implements Cloneable<Clazz>
{
public Clazz clone();
}
Can i avoid this?:
implements Cloneable<Clazz>
It will be simply implements Cloneable. Sorry for my english, i from Russia...
Well you could write implements Cloneable, but then you'd be using the raw type, which is generally a bad idea.
For the sake of stronger typing, you're better off sticking with what you've got.
If you leave out the <Clazz> it is treated as if you used <Object>.
If that is acceptable then go for it. Not recommended though unless you really want to lose some of your type safety.
Wasn't there a Java Puzzlers that mentioned this ... I can't find it.
Found it here. Go to about 38:00 where they are discussing the Glommer type.
Jon is correct - Raw types are not the same as <Object> and they are scary.
Solution: public interface Cloneable<T extends Cloneable<T>>
Compiles:
public class SerializableObject<T> implements Serializable
{
public T m_object;
}
Does NOT compile:
public class SerializableObject<T> extends T implements Serializable
{
}
So, I want a generic class to derive from its generic type parameter.
Why?
Let's say I have a Map<K, V> and I simply want to serialize it.
I also don't know ahead which keys I'll have.
How do I do that?
So, I want a generic class to derive from its generic type parameter.
You just can't do that, I'm afraid. There are various technical reasons for this, not least of which is type erasure.
You should look for an alternative solution to your issues - this idea is a dead end.
Nope, your goal is near a Dynamic type, which java does not support.