java generics - "extends" keyword -> not supporting add elements

Question

I am stuck with a strange problem due to java generics "extend" keyword. I have developed a generic method to get the elements from a method as generic as possible.

When I use <? extends X>, I am not able to add any elements to it.

In my case I am using the generic template to restrict the arguments provided by the user and providing the return type ac.

class Root{
    
}

class Sub_1 extends Root{
    
}

class Sub_2 extends Root{
    
}

public static <T extends Root> List<T> getSubElements(Class<T> targetClass){
    
    List<T> ls=new ArrayList<>();
    
    if(targetClass.getSimpleName().equals("Sub_1")){
        Sub_1 sub_1 = new Sub_1();
        ls.add(sub_1);
    }else if(targetClass.getSimpleName().equals("Sub_2")){
        Sub_2 sub_2=new Sub_2();
        ls.add(sub_2);
    }
    
    return ls;
}

In the above case, I am getting compilation error when I add elements to the list.

ls.add(sub_1);

ls.add(sub_2);

It looks quite challenging now to solve this issue.. I will be happy if someone can provide some hints here.

Thanks!!

Answer 1

If you can accept any class derived from Root, and all have a default constructor...

public static <T extends Root> List<T> getSubElements(Class<T> targetClass) throws ReflectiveOperationException {
    List<T> ls = new ArrayList<>();
    T t = targetClass.getDeclaredConstructor().newInstance();
    ls.add(t);
    return ls;
}

... or try/catch exception locally.

Answer 2

You can do this in a type-safe way, without using reflection, by having the caller pass in a Supplier of the desired type instead of the Class of that type. The getSubElement code then simply calls the supplier to get the right instance:

static <T extends Root> List<T> getSubElements(Supplier<T> s) {
    List<T> ls = new ArrayList<>();
    ls.add(s.get());
    return ls;
}

The caller needs to provide a way to create an instance of its desired subclass. This might be using a constructor reference, or it could be a reference to a static factory method. If the class hierarchy is like so:

public class Root { }

public class Sub1 extends Root {
    public Sub1() { ... }
}

public class Sub2 extends Root {
    public static Sub2 instance() { ... }
}

Then callers could write code like the following:

List<Sub1> list1 = getSubElements(Sub1::new);

List<Sub2> list2 = getSubElements(Sub2::instance);

Answer 3

To sum things up, here is a verified working implementation, checked using an online java compiler:

import java.util.*;

class Root{

}

class Sub_1 extends Root{

}

class Sub_2 extends Root{

}

public class Bla  {

    public static <T extends Root> T factoryMethod(Class<T> targetClass) throws Exception{
        if (Sub_1.class ==(targetClass)) {
            return (T) (new Sub_1());
        }
        else if (Sub_2.class == (targetClass)) {
            return (T) (new Sub_2());
        }
        else {
            throw new Exception("Unsupported class type");
        }
    }

    public static List<Root> getSubElements() throws Exception{

        List<Root> ls=new ArrayList<>();
        ls.add(factoryMethod(Sub_1.class));
        ls.add(factoryMethod(Sub_2.class));

        return ls;
    }

    public static void main(String[] args) {
        try {
            List<Root> root = getSubElements();
            System.out.println(root);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Answer 4

I would rather say the answer depends on boundary conditions. we can write code to get the necessary functionality but they may/may not adhere to various boundaries conditions like performance, security, integrity ,.. etc

e.g: The following code

**T newInstance = targetClass.newInstance();**
**list.add(newInstance);**

can also achieve necessary functionality but may/may not adhere to performance boundary, coz any call to reflective methods checks for security access.

The solution with Supplier posted above also achieves a similar functionality , but it may not adhere to security boundary as a malicious supplier can supply values which can lead to buffer overflow or DOS attacks. (if you really want to to try it out you can create a static supplier and initialize with self.. you will get an stack overflow. java generics book also provide a similar security related example which you can refer). The problem i see lies in the java open sub-typing in the current scenario .

There are other solutions also to achieve required functionality ( with slight modification to way of subtyping created) which may/may not adhere to these boundary conditions. The problem i see is due to open sub-typing system and makes it verbose and difficult for developers to write code adhering to all boundary conditions.

The solution also depends completely up on your model structure whether you have created a sub-typing coz of your data or or based on behavior , which might not reflect in this short example.

you can refer Java Generics Book by Philiph Wadler for more details on working with generics which i would recommend. it also gives an important aspect of writing code in a secure way. On an interesting note you can refer to project amber (java 11 or later) regarding Data Classes for java which tries to address some of these problems.