I'm uncomfortable with GenericsUtil. It can't be denied that Java generics have some fiercely annoying properties, but factoring this out is probably the wrong solution.
I cannot understand why we do not want to separate the functionality to deal with generics. The proposed functions are fairly general and can be used by others, and it seems that we cannot get rid of them(please see below), so extracting this out is better than introducing ad hoc solutions.
Where GenericsUtil::getClass(T) is called, Class::asSubclass(Class) should be preferred.
we cannot use Class::asSubclass(Class) get a Class<T> object where T is a generic type, because then we would use :
Class<T> c = item.getClass().asSubclass( <cannot_fill> );
in the above code, we cannot write anything as an argument to getSubclass, since we do not have any object of type Class<T>. (if we had then why would we bother getting an object of the same type). GenericsUtil#getClass(T) is introduced to handle the repetitive pattern of
Class<T> c = (Class<T>)t.getClass();
Similarly, GenericsUtil::toArray is called from a function that's destringifying and deserializing objects. It's not statically-checkable code, the casts are wholly justified, and the warning should be suppressed. Contexts where toArray might be useful should typically prefer the equally typesafe implementation in ArrayList (this case included).
Unfortunatelly, we cannot use ArrayList#toArray(T a), since creating a generic array is not allowed, similarly ArrayList#toArray() will not work either, since it returns an Object and casting Object to T is not possible. Thus we needed a method to do the job of returning a generic array from a List, that's why we have GenericsUtil::toArray(). The above cases are clearly demonstrated in TestGenericsUtil#testWithGenericClass().
Since separator is a constant, it should be in all caps
I would change that, if it matters.