Java Class.cast () против оператора приведения

Когда я учился на C ++ о пороках оператора приведения в стиле C, я сначала был рад обнаружить, что в Java 5 java.lang.Classесть castметод.

Я подумал, что наконец-то у нас появился ОО-подход к кастингу.

Оказывается, Class.castэто не то же самое, что static_castв C ++. Это больше похоже reinterpret_cast. Он не будет генерировать ошибку компиляции там, где она ожидается, а вместо этого будет отложена до времени выполнения. Вот простой тестовый пример, чтобы продемонстрировать различное поведение.

package test;

import static org.junit.Assert.assertTrue;

import org.junit.Test;


public class TestCast
{
    static final class Foo
    {
    }

    static class Bar
    {
    }

    static final class BarSubclass
        extends Bar
    {
    }

    @Test
    public void test ( )
    {
        final Foo foo = new Foo( );
        final Bar bar = new Bar( );
        final BarSubclass bar_subclass = new BarSubclass( );

        {
            final Bar bar_ref = bar;
        }

        {
            // Compilation error
            final Bar bar_ref = foo;
        }
        {
            // Compilation error
            final Bar bar_ref = (Bar) foo;
        }

        try
        {
            // !!! Compiles fine, runtime exception
            Bar.class.cast( foo );
        }
        catch ( final ClassCastException ex )
        {
            assertTrue( true );
        }

        {
            final Bar bar_ref = bar_subclass;
        }

        try
        {
            // Compiles fine, runtime exception, equivalent of C++ dynamic_cast
            final BarSubclass bar_subclass_ref = (BarSubclass) bar;
        }
        catch ( final ClassCastException ex )
        {
            assertTrue( true );
        }
    }
}

Итак, это мои вопросы.

1. Должно Class.cast()быть сослан в дженерик землю? Там у него довольно много законных применений.
2. Должны ли компиляторы генерировать ошибки компиляции при Class.cast()использовании, а недопустимые условия могут быть определены во время компиляции?
3. Должна ли Java предоставлять оператор приведения в качестве языковой конструкции, подобной C ++?

Я только когда-либо использовал, Class.cast(Object)чтобы избежать предупреждений в "стране дженериков". Я часто вижу такие методы:

@SuppressWarnings("unchecked")
<T> T doSomething() {
    Object o;
    // snip
    return (T) o;
}

Часто лучше заменить его:

<T> T doSomething(Class<T> cls) {
    Object o;
    // snip
    return cls.cast(o);
}

Это единственный случай использования, с которым Class.cast(Object)я когда-либо сталкивался.

Что касается предупреждений компилятора: я подозреваю, что Class.cast(Object)это не особенность компилятора. Его можно было бы оптимизировать при статическом использовании (то есть, Foo.class.cast(o)а не cls.cast(o)), но я никогда не видел, чтобы кто-нибудь его использовал, что делает попытки встроить эту оптимизацию в компилятор несколько бесполезной.

Во-первых, вам категорически не рекомендуется использовать практически любые заклинания, поэтому вам следует максимально ограничить их! Вы теряете преимущества строго типизированных функций Java во время компиляции.

В любом случае его Class.cast()следует использовать в основном при получении Classтокена через отражение. Писать более идиоматично

MyObject myObject = (MyObject) object

скорее, чем

MyObject myObject = MyObject.class.cast(object)

EDIT: ошибки во время компиляции

В целом Java выполняет проверку приведения только во время выполнения. Однако компилятор может выдать ошибку, если сможет доказать, что такое приведение не может быть успешным (например, приведение класса к другому классу, не являющемуся супертипом, и приведение окончательного типа класса к классу / интерфейсу, не входящему в его иерархию типов). Здесь, поскольку Fooи Barявляются классами, не входящими в иерархию друг друга, приведение не может быть успешным.

Всегда проблематично и часто вводить в заблуждение пытаться переводить конструкции и концепции между языками. Кастинг - не исключение. В частности, потому что Java - это динамический язык, а C ++ несколько отличается.

Все приведение типов в Java, независимо от того, как вы это делаете, выполняется во время выполнения. Информация о типе хранится во время выполнения. C ++ - это немного больше смесь. Вы можете преобразовать структуру в C ++ к другой, и это просто переинтерпретация байтов, которые представляют эти структуры. Java так не работает.

Также дженерики в Java и C ++ сильно отличаются. Не беспокойтесь слишком о том, как вы делаете вещи C ++ в Java. Вам нужно научиться делать что-то на языке Java.

Class.cast()редко когда-либо используется в коде Java. Если он используется, то обычно с типами, которые известны только во время выполнения (т. Е. Через их соответствующие Classобъекты и какой-либо параметр типа). Это действительно полезно только в коде, который использует дженерики (это также причина, по которой он не был представлен ранее).

Это не похоже на reinterpret_cast, потому что это не позволит вам нарушить систему типов во время выполнения, как и обычное приведение (т.е. вы можете нарушить параметры универсального типа, но не можете сломать «настоящие» типы).

Пороки оператора приведения в стиле C обычно не относятся к Java. Код Java, который выглядит как приведение в стиле C, больше всего похож на код dynamic_cast<>()со ссылочным типом в Java (помните: Java имеет информацию о типе времени выполнения).

Обычно сравнивать операторы приведения C ++ с приведением Java довольно сложно, поскольку в Java вы можете приводить только ссылку, и никакое преобразование никогда не происходит с объектами (с использованием этого синтаксиса можно преобразовать только примитивные значения).

Обычно оператор приведения предпочтительнее метода приведения Class #, поскольку он более краток и может быть проанализирован компилятором, чтобы выявить явные проблемы с кодом.

Class # cast берет на себя ответственность за проверку типов во время выполнения, а не во время компиляции.

Несомненно, существуют варианты использования приведения Class #, особенно когда дело доходит до отражающих операций.

Поскольку лямбда пришла в java, мне лично нравится использовать приведение Class # с API коллекций / потоков, например, если я работаю с абстрактными типами.

Dog findMyDog(String name, Breed breed) {
    return lostAnimals.stream()
                      .filter(Dog.class::isInstance)
                      .map(Dog.class::cast)
                      .filter(dog -> dog.getName().equalsIgnoreCase(name))
                      .filter(dog -> dog.getBreed() == breed)
                      .findFirst()
                      .orElse(null);
}

C ++ и Java - разные языки.

Оператор приведения типа Java в C намного более ограничен, чем версия C / C ++. Фактически приведение Java похоже на C ++ dynamic_cast, если имеющийся у вас объект не может быть приведен к новому классу, вы получите исключение времени выполнения (или, если в коде достаточно информации, время компиляции). Таким образом, идея C ++ об отказе от приведений типов C не является хорошей идеей в Java.

В дополнение к удалению уродливых предупреждений о приведении, как уже упоминалось, Class.cast - это приведение во время выполнения, в основном используемое с универсальным приведением, из-за того, что общая информация будет удалена во время выполнения, и некоторым образом каждый общий будет считаться объектом, это приводит к тому, что выбросить раннее исключение ClassCastException.

например serviceLoder использует этот трюк при создании объектов, проверьте S p = service.cast (c.newInstance ()); это вызовет исключение приведения класса, когда SP = (S) c.newInstance (); не будет и может отображать предупреждение «Типовая безопасность: отключенное приведение от объекта к S» . (то же, что и Object P = (Object) c.newInstance ();)

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

Реализация java для динамического приведения:

@SuppressWarnings("unchecked")
public T cast(Object obj) {
    if (obj != null && !isInstance(obj))
        throw new ClassCastException(cannotCastMsg(obj));
    return (T) obj;
}




    private S nextService() {
        if (!hasNextService())
            throw new NoSuchElementException();
        String cn = nextName;
        nextName = null;
        Class<?> c = null;
        try {
            c = Class.forName(cn, false, loader);
        } catch (ClassNotFoundException x) {
            fail(service,
                 "Provider " + cn + " not found");
        }
        if (!service.isAssignableFrom(c)) {
            fail(service,
                 "Provider " + cn  + " not a subtype");
        }
        try {
            S p = service.cast(c.newInstance());
            providers.put(cn, p);
            return p;
        } catch (Throwable x) {
            fail(service,
                 "Provider " + cn + " could not be instantiated",
                 x);
        }
        throw new Error();          // This cannot happen
    }

Лично я использовал это раньше для создания конвертера JSON в POJO. В случае, если JSONObject, обработанный с помощью функции, содержит массив или вложенные JSONObject (подразумевая, что данные здесь не примитивного типа или String), я пытаюсь вызвать метод установки, используя class.cast()следующим образом:

public static Object convertResponse(Class<?> clazz, JSONObject readResultObject) {
    ...
    for(Method m : clazz.getMethods()) {
        if(!m.isAnnotationPresent(convertResultIgnore.class) && 
            m.getName().toLowerCase().startsWith("set")) {
        ...
        m.invoke(returnObject,  m.getParameters()[0].getClass().cast(convertResponse(m.getParameters()[0].getType(), readResultObject.getJSONObject(key))));
    }
    ...
}

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