Узнаем параметр Generic-класса в Java

Скорее на
public class FloatList extends ArrayList<Float> {}

Пример ситуации: в слое представления есть формы с таблицами. Столбцы в таблицах — соотносятся с полями некоторых сущностей в модели данных (в одной таблице могут присутствовать поля из разных связанных сущностей). Задача: организовать фильтрацию и сортировку по столбцам таблиц средствами базы данных. То есть нужно преобразовать информацию о том, какие столбцы таблицы выбраны для фильтрации/сортировки в информацию о полях сущностей, потом по этой информации построить Criteria для выборки данных, получить данные и развернуть цепочку в обратном направлении. Вот для всего этого на некоторых этапах понадобилась возможность анализировать параметры (хотя есть обходные пути).

например, для написания Generic DAO.
В Hibernate / Seam так делают

вполне удобно

Думаю Автор бывший .NET-чик, потому что в .NET-е Generic-и работают на runtime-е.

В JAVA изза обратной совместимости Generic — и работают только в compile time, в отличие от .NET-а, в котором существует две копии библиотек колекций: с generic-ами и без.

На JAVA такого рода задачи лучше решать.

abstract class Base<X>{
    public abstract Class<X> getXType();
}

class MyClass extends Base<String>{
    public Class<String> getXType(){
        return String.class;
    }
}

Хочу также обратить внимание на парамертрезированый тип Class метода getXType, так как это являеться хороши тоном в JAVA.

Это также являеться хорошим примером Strong Typed программировния, потому что конструкция abstract/Class всегда будет следить за тем что getXType возвращает именно тот тип который указан в качестве generic-а.

Спасибо, за ценное замечание. Плюс вам в карму. Действительно, забыл учесть эту ситуацию, хотя и хотел :)

Внес исправления в код.

По-хорошему — так и нужно делать. То есть передавать в конструктор реальный класс, а не искать его так как описано в топике. Это просто, надёжно и полностью корректно.

Но иногда — это не очень удобно: довешивать в конструкторы дополнительный параметр. Особенно — если классов сотни, а ты можешь гарантировать, что все они будут параметризованы при наследовании. Собственно это и стало причиной топика.

Чёрт, комментарий отправился раньше, чем нужно.
Так вот

    if (!(result instanceof Class)) {
      // Похоже, что параметр - массив, примитивный типи, интерфейс или еще-что-то, что не является классом.
      throw new IllegalStateException("Actual parameter type for " + actualClass.getName() + " is not a Class.");
    }

Вообще говоря, массив, примитивный тип и интерфейс являются классами (см. Class#isArray(), Class#isPrimitive(), Class#isInterface(); если точнее, то примитивы — не классы, но для них есть соответствующие классы).

Правда, если параметризовать класс-родитель массивом, то параметр действительно вернётся не как Class, а как GenericArrayType — и это единственный возможный случай попасть в этот блок кода. Потому что примитивным типом вообще нельзя параметризовать класс-родитель.
Ещё один наследник (кроме, собственно, GenericArrayType, ParameterizedType, TypeVariable и Class) интерфейса Type — WildcardType (представляющий wildcard'ы) — и им тоже, как и примитивом, нельзя параметризовать класс-родитель при наследовании.

Да, есть. Добавил архив к статье.

Правда там более поздняя версия утилиты — теперь поддерживается извлечение информации из интерфейсов, а не только из классов. Если нужны будут пояснения — могу набросать отдельную небольшую статью.

Поясните, чем она аналогична? Не наблюдаю в ней решения проблемы, описанной в топике. Если вы про метод getSuperclassTypeParameter(...), то он представляет собой как раз то, от чего я отказался в начале статьи по причине ограниченности применения.