Develop Reference

Java generics incompatible types while subclassing

While sub classing from generic class type/Formal type parameter T/E with valid class type/Actual type parameter say e.g. Type/String there are many combinations occurs and that confusing which one to use and when?
public class SubClass<T> implements SuperIfc<T> <-- It is straight forward to understand
public class SubClass<T> implements SuperIfc<Type>
public class SubClass<Type> implements SuperIfc<T>
public class SubClass<Type> implements SuperIfc<Type>
public class SubClass<Type> implements SuperIfc
public class SubClass implements SuperIfc<Type>
public class SubClass implements SuperIfc<T> <--- Hope we cannot declare <T> in his case while initialising SubClass.
// Bounded type parameter
public class SubClass<T extends Type> implements SuperIfc<Type>
public class SubClass<T extends Type> implements SuperIfc<T> <-- Looks <T> at SuperIfc also refers <T extends Type>, and no need to declare it again at SuperIfc.
// Recursive type bound
public class SubClass<T extends Comparable<T>>> implements SuperIfc<T>
public class SubClass<T extends Comparable<T>>> implements SuperIfc<Type>
So that i can be more clearer on solving incompatible types while subclassing
Case_1:
public class Test {
interface TestIfc {
public static <T extends TestIfc> T of(int choice) {
if(choice == 1) {
return new TestImpl(); <-- PROB_1: incompatible type error
} else {
return new SomeOtherTestImpl(); //incompatible type error
}
}
}
static class TestImpl implements TestIfc {}
static class SomeOtherTestImpl<T extends TestIfc> implements TestIfc {
//The below method also having same error though with declaration
public T of() {
return new TestImpl(); <-- PROB_2: incompatible type error
}
}
}
Case_1: PROB_1: return type is T extends TestIfc and returned TestImpl implements TestIf So what is wrong?
Case_1: PROB_2: Similar to PROB_1, how to rectify without external casting. Please help.
Case_2:
public interface SuperIfc<T> {
public T create(Object label);
}
class Type {
public static Type of(){
return new Type();
}
}
------
public class SubClass<Type> implements SuperIfc<Type>{
#Override
public Type create() {
return Type.of(); <---- PROB_1: cannot resolve method
}
}
-------
public class SubClass<T extends Type> implements SuperIfc<Type>{
#Override
public Type create() {
return Type.of(); <---- PROB_1: is resolved
}
}
SuperIfc<Type> object = new SubClass(); <-- PROB_2 Unchecked assignement warning
SuperIfc<Type> object = new SubClass<TypeImpl>(); <-- PROB_3: bound should extend Type
I would like to know how to resolve Case_2, PROB_1 and PROB_2 together?
How to write subclass for generic super class with class types and what are the rules?
What should be taken care when changing generic T to class Type while subclassing? may be the difference between below and when to use?
public class SubClass<Type> implements SuperIfc<Type>
public class SubClass<Type> implements SuperIfc
public class SubClass implements SuperIfc<Type>
public class SubClass<T extends Type> implements SuperIfc<Type>
public class SubClass<T extends Type> implements SuperIfc<T>
public class SubClass<T> implements SuperIfc<Type>

In the first of() method, the method can return any type that implements InformationIfc, but your method always returns a specific implementation - InformationImpl - which is not acceptable.
For example, if you had some other class SomeOtherInformationImpl that implements that interface, the caller of that method would be allowed to write:
SomeOtherInformationImpl i = InformationImpl.of();
but your method doesn't return a SomeOtherInformationImpl.
The second of() method has the same issue as the first method.
If you instantiated your class with:
InformationImpl i = new InformationImpl<SomeOtherInformationImpl>();
the of() method would have to return a SomeOtherInformationImpl, not a InformationImpl.

Problems with case one.
PROB_1: return type is T extends TestIfc
Why do you have a generic here at all?. Since you have a static method I can do.
TestIfc broken = TestIfc<SomeOtherImplementation>.of(0);
SomeOtherImplementation is not a TestImpl. This is broken by design. What you really want is.
public static TestIfc of(int choice)
Next.
static class SomeOtherTestImpl<T extends TestIfc> implements TestIfc {
TestIfc is not parameterized, SomeOtherTestImp is, but it is completely unrelated to the interface you're implementing. Not to mention, TestIfc has a static method of that has nothing to do with the interface.
If I had to guess, I would think you want.
interface TestIfc<T>{}
static class TestImpl implements TestIfc<TestImpl> {}
static class SomeOtherTestImpl<T extends TestIfc> implements TestIfc<T>{}
That is the best I could come up with, because it is unclear what you actually want to happen.
Your examples for question 3
public class SubClass<Type> implements SuperIfc<Type>
This is broken, because SubClass<Type> declares Type to be the name of a generic parameter. It puts no restriction on the type, hence you get the method not found error.
public class SubClass<Type> implements SuperIfc
Broken, makes a generic parameter named Type, has nothing to do with your raw type version of SuperIfc
public SubClass implements SuperIfc<Type>
This is good.
public class SubClass<T extends Type> implements SuperIfc<Type>
public class SubClass<T> implements SuperIfc<Type>
These are both good, but the T has no relation to the SuperIfc parameter, hence your implementation would be.
public Type create(Object label);
The first generic parameter says the name you're going to use through the class.

This is a long answer, but please read through it (at least case 1 and the very end, you can skip over problem 2's solution in case 2 if you wish)
Case 1
Problem 1:
Your problem here is that the compiler cannot prove that T is the same as TestImpl or SomeOtherTestImpl. What if there was another class, call it TestFoo, that implemented TestIfc? Then, if you called the method as TestIfc.<TestFoo>of(1), you would expect an object of type TestFoo, but you would instead get a TestImpl, which is wrong. The compiler doesn't want you doing that, so it throws an error. What you should do is just remove the generics, like so:
public static TestImpl of(int choice) {
if(choice == 1) {
return new TestImpl();
} else {
return new SomeOtherTestImpl();
}
}
And then you can safely call TestIfc.of.
Problem 2:
This is basically the same thing. The compiler can't prove that the type parameter T of SomeOtherTestImpl is the same as TestImpl. What if you have an object like this (where TestFoo does not extend TestImpl but implements TestIfc)?
SomeOtherTestImpl<TestFoo> testImpl = ...;
And then you try to call the of method like this:
TestFoo testFoo = testImpl.of();
Can you see the problem here? Your of method returns a TestImpl, but you expect it to return a TestFoo because T is TestFoo. The compiler stops you from doing that. Again, you should just get rid of the generics:
public TestImpl of() {
return new TestImpl(); //This works now
}
Case 2
Problem 1
This problem is caused simply because you named your type parameter the same thing as your class - Type. When you changed the name of your type parameter to, say, T, it'll work because now Type is the name of a class. Before, your type parameter Type was hiding the class Type.
However, again, there is no need for a type parameter, since, you can just do this, and it'll satisfy all constraints.
public class SubClass implements SuperIfc<Type> {
#Override
public Type create() {
return Type.of();
}
}
Problem 2:
The unchecked assignment is because you didn't provide type arguments to SubClass when you did
SuperIfc<Type> object = new SubClass();
This can be fixed by either explicitly giving Type to SubClass:
SuperIfc<Type> object = new SubClass<Type>();
or by putting in an empty diamond (which I much prefer). This second approach means that the compiler can infer by itself that by new Subclass<>(), you mean new Subclass<Type>().
SuperIfc<Type> object = new SubClass<>();
Why the compiler complains:
That constructor call (new Subclass()) is basically like calling a method that looks like public SubClass makeNewSubClass() {...}. In fact, let's replace that statement above with this one, which will cause the same warning.
SuperIfc<Type> object = makeNewSubClass();
SubClass normally takes 1 type parameter (call it T), but here, it's not given any type parameters. That means that T could be anything, any class that extends Type (because of the constraint SubClass<T extends Type>).
You might thinking that if T is always going to be a subclass of Type, it should work all right, because the type of object above is SuperIfc<Type>. Assume there's a class like this - class TypeFoo extends Type - and that the method makeNewSubClass actually returns an object of type SubClass<TypeFoo> (new SubClass<TypeFoo>()).
Because of this, you expect object to be SuperIfc<Type> but it's actually SubClass<TypeFoo>. You probably think that that's all right, because after all, TypeFoo is a subclass of Type, right? Well, Java's generics are actually invariant, which means that for the compiler, SubClass<TypeFoo> is not a subclass of SuperIfc<Type> - it thinks they're 2 completely unrelated types. Don't ask me - I have no idea why :). Even SubClass<TypeFoo> isn't considered the same as or a subclass of SubClass<Type>!
That's why the compiler emits a warning - because raw types (that's what you call it when you have new SubClass() without giving type arguments) could represent anything. As for why it emits a warning and not an error - generics were introduced in Java 5, so for code before that to compile, the compiler lets you off with just a warning.
Problem 3:
According to the error, the type argument you gave (TypeImpl) should extend Type. This is because you defined SubClass as class SubClass<T extends Type> .... Here, you are giving TypeImpl as an argument for T, and so TypeImpl must extend Type, so all you need to do is put do class TypeImpl extends Type to solve that particular error.
However, even after you do that, you'll get an "incompatible types" error because, as I said earlier when talking about Problem 2, SuperIfc<Type> is not considered a supertype of SubClass<TypeImpl> even if TypeImpl extends Type.
You can do this
SuperIfc<TypeImpl> object = new SubClass<TypeImpl>();
or you can do this
SuperIfc<? extends Type> object = new SubClass<TypeImpl>();
In the second solution, we lose the information of what exactly T is in SuperIfc<T>; all we know is that it extends Type. The benefit of the second one is that you can later reassign any SubClass object to it (which doesn't work with the first version because it only allows SubClass<TypeImpl>:
SuperIfc<? extends Type> object = new SubClass<TypeImpl>();
object = new SubClass<Type>(); //works great
Alternative solution for Case 2
What it seems like you want to do is return objects of different type depending on type parameters. That's not really possible to do, since type parameters are erased at runtime. There are workarounds, though.
Here's one way to do it with a functional interface. It involves no casting and ensures type safety.
//This is the functional interface. You can also use Supplier here, of course
interface Constructor<T> {
T create();
}
class SubClass<T extends Type> implements SuperIfc<T> {
public Constructor<T> ctor;
public SubClass(Constructor<T> ctor) {
this.ctor = ctor;
}
#Override
public T create(Object label) {
return ctor.create();
}
}
class Type {}
class TypeImpl extends Type{}
By using a Constructor object, you will know that the returned Type object will always be of the right type. This is very easy to apply to your existing code - you don't need to write your own ConstructorImpl classes or anything.
You can now write this, and all you need to add is a method reference to the constructor (Type::new).
SuperIfc<Type> object1 = new SubClass<>(Type::new);
SuperIfc<? extends Type> object2 = new SubClass<>(TypeImpl::new);
With lambdas, you can also write this in a slightly more verbose way:
SuperIfc<TypeImpl> object = new SubClass<>(() -> new TypeImpl());
---
SuperIfc<? extends Type> object = new SubClass<>(() -> new TypeImpl());

EnumSet as a parameter in generic Interface

I've a use case :
inteface A{
get(EnumSet<?> fetchModes);
}
class B implements A{
//Here FetchMode is an enum
get(EnumSet<FetchMode> fetchMode){
//Some logic here
}
}
But it's throwing compile time error :
Method get of class B has the same erasure as get(EnumSet fetchMode) of type A but doesn't override it.
I had read that Enums cannot be generic but is there any way to implement this usecase ?
(Basically want the EnumSet to be generic and different implementations can pass different Enums)

A method can override another if the argument types match exactly, but yours doesn't. Eventhough EnumSet<FetchMode> is a subtype of EnumSet<?>, they are not exactly the same. You are not overriding the super class method get(EnumSet<?> fetchModes); in your subclass, rather you are overloading it with a different parameter type. Both of these has the same signature due to erasure when you inspect or decompile the bytecode which is get(EnumSet fetchModes) and your compiler starts complaining.
This is covered in JLS §8.4.8.1:
A class cannot have two member methods with the same name and type
erasure
A naive attempt at fixing the problem is to change the parameter type such that it is compatible with that of the super class, overriding the method properly in your sub class.
#Override
public void get(EnumSet<?> fetchModes) {
}
Though this fixes the compiler error after a fashion, it is still not elegant since it allows your EnumSet to store any Object. But ideally you may want it to store only some subtype of Enum. This idiom supports that.
What you have to do is declare a generic interface with bounded type parameter and then implement it by overriding the method properly as shown below.
public interface A<E extends Enum<E>> {
void get(EnumSet<E> fetchModes);
}
public class B implements A<FetchMode> {
#Override
public void get(EnumSet<FetchMode> fetchModes) {
}
}

try this you have to make the generic type extends Enum:
public class B implements A<FetchMode> {
//Here FetchMode is an enum
public void get(EnumSet<FetchMode> fetchMode){
//Some logic here
}
}
}
interface A<T extends Enum<T>> {
void get(EnumSet<T> fetchModes);
}

Generics and varargs java

Below is my set up
public interface Test<T extends MyInterface>
{
someMethod(T... a)
}
public class TestImpl implements Test<MyInterfaceImpl>
{
someMethod(MyInterfaceImpl... a)
}
public class MyInterfaceImpl implements MyInterface {}
public someClass { #Autowired TestFactory testfactory
......
// getting an error -- Type mismatch Can't assign non-array value to an array
testfactory.getTest(Type type).someMethod(new MyInterfaceImpl())
}
public class TestFactoryImpl implements TestFactory { Test getTest(Type type) { return registry.get(type)}}
which in turn is results in java.lang.ClassCastException: [Lcom.test.MyInterface; cannot be cast to [Lcom.test.Impl.MyInterfaceImpl;
but the below works
testfactory.getTest(Type type).someMethod(new MyInterfaceImpl[]{new MyInterfaceImpl()})
Not sure what is happening. Help please

Ok .. the problem is within the design of your already existing code (which you can't change). Having public interface Test<T extends MyInterface> and then public class TestImpl implements Test<MyInterfaceImpl> is wrong.
TestImpl is implementing Test with MyInterfaceImpl whereas the original Test interface only expects an object that extends MyInterface and not implement it.
There will be a type confusion at runtime when executing the code. Not only does the following line throw a ClassCastException
test.someMethod(new MyInterfaceImpl());
but also test.someMethod(); by itself throws an exception. So let's say if you factory called this method passing no argument, you would still get an exception as the original designed is flawed. In a normal situation test.someMethod(); should not throw an exception to begin with. You will need to talk to the appropriate party to put a fix to this serious issue.
Below is a sample solution:
The method someMethod(MyInterface...) belongs to the raw type Test. References to generic type Test<T> should be parameterized.
This means you should Test<MyInterfaceImpl> test to avoid getting this error with only the new operator.
Test<MyInterfaceImpl> test
...
test.someMethod(new MyInterfaceImpl());
The above code will work with no problem.

A better solution is in your TestImpl class do the following
public class TestImpl implements Test<MyInterface>{...}
instead of
public class TestImpl implements Test<MyInterfaceImpl>{...}
That way you don't need to explicitly parameterize your object instance (i.e. you could just do
Test test
...
test.someMethod(new MyInterfaceImpl());
)

Java generics: Generic parameter defined at method level vs interface level

I'm having the following issue to do with generics. I have the following:
InterfaceA as:
public interface InterfaceA {
public <T extends DTOInterface> Object methodName (T dto) {}
}
DTOInterface is just an empty interface.
Then my implementation would be:
public class ImplementationA implements InterfaceA {
public Object methodName(DTOImplementation dto) {
return null;
}
}
DTOImplementation is just a class implementing DTOInterface.
This is failing because the method in ImplementationA is not recognized as a valid implementation of the method in InterfaceA.
However, if I define the parameter at interface level i.e.
public interface InterfaceA **<T extends DTOInterface>** {
public Object methodName (T dto) {}
}
And then define the implementation as:
public class ImplementationA implements **InterfaceA<DTOImplementation>** {
public Object methodName(DTOImplementation dto) {
return null;
}
}
It does work. The method is recognized as a valid implementation.
Does anyone know why this is happening?

The first declaration says that in order to implement InterfaceA, the subclass needs to provide a method methodName that works for any type T that extends DTOInterface of the method caller's choice. In other words, T is a parameter that the caller of methodName gets to choose; the class that implements InterfaceA doesn't get to choose it. So when you provide an implementation that attempts to choose a particular value of T for methodName and only implement that, the compiler rejects your program.
The second declaration, on the other hand, is an interface that allows the implementor to provide a particular value for T and only implement its methods for that particular choice. ImplementationA choose to implement InterfaceA only for one particular subtype of DTOInterface (namely, DTOImplementation) and provides a method only for that choice of T. That's perfectly fine.

Your interface definition has a generic method
public <T extends DTOInterface> Object methodName (T dto) {}
This method states that it takes any type T that extends DTOInterface. If you want to implement the interface you need to provide the exact same method in the implementation.
You cannot restrict the method in an implementation because what would happen if you did this:
AnotherDTOImplementation adi = new AnotherDTOImplementation();
InterfaceA obj = new ImplementationA();
ojb.methodName(adi);
This obviously breaks type safety.
In your second example you have a generic interface. This means that when you implement the interface you either have to declare the generic type of specify the implementation as a generic class.
This means that ImplementationA is of type InterfaceA<DTOImplementation> which in turn means that you have type safety.

Java Generic classes assignability [duplicate]

This question already has answers here:
Multiple wildcards on a generic methods makes Java compiler (and me!) very confused
(3 answers)
Closed 8 years ago.
I have the following classes:
public interface ModelObject {
}
public interface Resource {
}
public interface Transformer <F,T>{
}
public interface WrapperFactory {
Transformer<Resource, Wrap<? extends ModelObject>> createMapper();
}
public class Wrap<E extends ModelObject> {
}
public class AbstractBaseTransformer<F,T> implements Transformer<F,T> {
}
public class ConcreteModel implements ModelObject {
}
public class ConcreteTransformer extends AbstractBaseTransformer<Resource, Wrap<ConcreteModel>> {
}
public class ConcreteFactory implements WrapperFactory {
#Override
public Transformer<Resource, Wrap<? extends ModelObject>> createMapper() {
return new ConcreteTransformer();
}
}
The ConcreteFactory doesn't compile stating that ConcreteTransformer is incompatible with returned
Transformer<Resource, Wrap<? extends ModelObject>>
I can't see what's wrong here. ConcreteTransformer binds 1st parameter to Resource (same as expected) while binding 2nd parameter to:
Wrap<ConcreteModel>
which should bind to:
Wrap<? extends ModelObject>
as ConcreteModel implements it.

Here is a simpler version, to narrow down the issue:
interface ModelObject {}
class ConcreteModel implements ModelObject {}
class Wrap<E extends ModelObject> {}
class SomeGeneric<T> {}
class Simple {
public SomeGeneric<Wrap<? extends ModelObject>> m() {
return new SomeGeneric<Wrap<ConcreteModel>>();
}
}
does not compile either.
Your problem is that a SomeGeneric<Wrap<ConcreteModel>> is not a SomeGeneric<Wrap<? extends ModelObject>>.

Wrap<ConcreteModel> is a subtype of Wrap<? extends ModelObject>? Yes.
Transformer<Resource, Wrap<ConcreteModel>> is a subtype of Transformer<Resource, Wrap<? extends ModelObject>>? No.
It's the same as:
String is a subtype of Object? Yes.
List<String> is a subtype of List<Object>? No.
Basically, for parameterized types to be compatible, if the top-level parameter is not wildcard, then the parameters must match exactly. In your case, the top-level parameter is not wildcard, and the parameters don't match exactly.
What you probably wanted instead was
Transformer<Resource, ? extends Wrap<? extends ModelObject>>

A Wrap<ConcreteModel> can be assigned to a variable of type Wrap<? extends ModelObject>. But the matter here is more complex.
Assume you have a ArrayList<Wrap<? extends ModelObject>> list. When you have such a type, it means that you can add a Wrap<ConcreteModel> to the list, but it also means that you can add a Wrap<ModelObject> to it. In brief, it means you have a list, that can contain a Wrap of anything that can be cast to a ModelObject.
On the other side, having a ArrayList<Wrap<ConcreteModel>> list means you can only add Wrap<ConcreteModel>s to it, while a Wrap<ModelObject> cannot be added to it, because the list can only contain wrapped ConcreteModels, and a wrapped ModelObject is not a wrapped ConcreteModel nor it can be cast to be one.
This is exactly your case. You declared your createMapper() method to return a Transformer<Resource, Wrap<? extends ModelObject>>. This means that the second argument of the returned Transformer must be able to be any subclass of ModelObject, including ModelObject itself. On the contrary, you are trying to return a Transformer<Resource, Wrap<ConcreteModel>>.
The compiler needs to enforce this because Transformer<F, T> could declare a method:
void myMethod(F fObject, T tObject);
If that was the case, the method myMethod of an object of type Transformer<Resource, Wrap<? extends ModelObject>> would accept an object of type ModelObject as its second argument. On the other side, the same method, in a object of type Transformer<Resource, Wrap<ConcreteModel>> cannot accept a ModelObject as its second argument.