Зачем мне использовать java.lang.Class.cast

Я не думаю, что его часто используют именно так, как вы показали. Наиболее частое использование, которое я видел, - это когда люди, использующие дженерики, пытаются сделать эквивалент этого:

public static <T extends Number> T castToNumber(Object o) {
    return (T)o;
}

Что на самом деле не делает ничего полезного из-за стирания типа.

Принимая во внимание, что это работает и безопасно по типу (по модулю ClassCastExceptions):

public static <T extends Number> T castToNumber(Object o, Class<T> clazz) {
    return clazz.cast(o);
}

РЕДАКТИРОВАТЬ: пара примеров использования google guava:

• MutableClassToInstanceMap
• Симпатичное использование в Throwables #progateIfInstanceOf, для типобезопасной общей спецификации throw

В Java часто есть несколько способов снять шкуру с кошки. Такая функциональность может быть полезна в тех случаях, когда у вас есть код фреймворка. Представьте себе метод, который принимает экземпляр объекта класса и экземпляр объекта и возвращает случай объекта как класс:

public static void doSomething(Class<? extends SomeBaseClass> whatToCastAs,Object o)
    {
        SomeBaseClass castObj =  whatToCastAs.cast(o);
        castObj.doSomething();
    }

В общем, используйте более простое приведение, если этого недостаточно.

В некоторых случаях вы знаете только тип для приведения объекта во время выполнения, и именно тогда вам нужно использовать метод приведения.

Абсолютно незачем писать Foo.class.cast(o), это эквивалент (Foo)o.

В общем, если X является реифицируемым типом и Class<X> clazz, то clazz.cast(o) совпадает с (X)o.

Если все типы реифицируемы, метод Class.cast() будет избыточным и бесполезным.

К сожалению, из-за стирания в текущей версии Java не все типы реифицируемы. Например, переменные типа не могут быть преобразованы.

Если T является переменной типа, приведение (T)o не отмечено флажком, поскольку во время выполнения точный тип T неизвестен JVM, JVM не может проверить, действительно ли o является типом T. Приведение может быть разрешено ошибочно, что может вызвать проблемы позже.

Это не большая проблема; обычно, когда программист делает (T)o, он уже рассудил, что приведение безопасно и не вызовет никаких проблем во время выполнения. Приведение проверяется логикой приложения.

Предположим, что Class<T> clazz доступен в точке приведения, тогда мы действительно знаем, что T во время выполнения; мы можем добавить дополнительную проверку времени выполнения, чтобы убедиться, что o действительно T.

check clazz.isInstance(o);
(T)o;

И это, по сути, то, что делает Class.cast().

Мы ни в коем случае не ожидаем, что приведение типов завершится неудачно, поэтому в правильно реализованном приложении проверка clazz.isInstance(o) всегда должна завершаться успешно, поэтому clazz.cast(o) эквивалентно (T)o - опять же, в предположении, что код правильный.

Если можно доказать, что код правильный и приведение безопасно, можно было бы предпочесть (T)o clazz.cast(o) по соображениям производительности. В примере MutableClassToInstanceMap, поднятого в другом ответе, мы, очевидно, видим, что приведение безопасно, поэтому простого (T)o было бы достаточно.

class.cast предназначен для типа generics.

Когда вы создаете класс с универсальным параметром T, вы можете передать Class. Затем вы можете выполнить приведение как со статической, так и с динамической проверкой, чего не дает (T). Он также не выдает непроверенных предупреждений, потому что он отмечен (в этот момент).

Обычный пример для этого - когда вы извлекаете из постоянного слоя коллекцию сущностей, на которые ссылается объект класса и некоторые условия. Возвращенная коллекция может содержать непроверенные объекты, поэтому, если вы просто приведете ее как указанную G_H, вы вызовете исключение Cast Exception в этот момент, а не при доступе к значениям.

Один из примеров этого - когда вы извлекаете коллекцию из DAO, которая возвращает непроверенную коллекцию, и в своей службе вы выполняете итерацию по ней, эта ситуация может привести к ClassCastException.

Один из способов решить эту проблему, поскольку у вас есть требуемый класс и непроверенная коллекция, - это перебрать его и передать его внутри DAO, преобразовав коллекцию в проверенную коллекцию и затем вернув ее.

Потому что у вас может быть что-то такое:

Number fooMethod(Class<? extends Number> clazz) {
    return clazz.cast(var);
}

"Приведение" в Java, например (Number)var, где объект в круглых скобках является ссылочным типом, на самом деле состоит из двух частей:

• Время компиляции: результат выражения приведения имеет тип типа, к которому вы приводите
• Время выполнения: он вставляет операцию проверки, которая в основном говорит, что если объект не является экземпляром этого класса, затем выдает ClassCast Exception (если то, что вы выполняете, является переменной типа, тогда проверяемый класс будет нижняя граница переменной типа)

Чтобы использовать синтаксис, вам нужно знать класс во время написания кода. Предположим, вы не знаете во время компиляции, к какому классу хотите привести приведение; вы знаете это только во время выполнения.

Вы спросите, а в чем тогда смысл кастинга? Разве цель кастинга не заключается в том, чтобы во время компиляции преобразовать выражение в желаемый тип? Так что, если вы не знаете тип во время компиляции, тогда нет никакого преимущества во время компиляции, верно? Верно, но это только первый пункт выше. Вы забываете компонент времени выполнения приведения (второй элемент выше): он проверяет объект на соответствие классу.

Следовательно, цель приведения во время выполнения (т.е. Class.cast()) состоит в том, чтобы проверить, является ли объект экземпляром класса, и, если нет, выбросить исключение. Это примерно эквивалентно этому, но короче:

if (!clazz.isInstance(var))
    throw new ClassCastException();

Некоторые люди упоминали, что Class.cast() также имеет хороший тип возвращаемого значения, основанный на параметре типа переданного класса, но это просто функция времени компиляции, которая в любом случае обеспечивается преобразованием во время компиляции. Так что для этой цели нет смысла использовать Class.cast().