Java Class.cast（）与强制转换运算符

在我的C ++时代里，学习过C风格的强制转换运算符的弊端后，我最初很高兴地发现Java 5中java.lang.Class已经获得了一种cast方法。

我以为最终我们有了一种面向对象的处理铸造的方法。

事实证明Class.cast与static_castC ++不同。更像是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)

编辑：编译时错误

总体而言，Java仅在运行时执行强制检查。但是，如果编译器可以证明此类强制转换永远不会成功，则编译器可能会发出错误（例如，将一个类强制转换为非超类型的另一个类，并将最终的类类型强制转换为不在其类型层次结构中的类/接口）。在这里，由于Foo和Bar是不在彼此层次结构中的类，因此强制转换永远不会成功。

尝试在语言之间翻译构造和概念总是有问题的，并且常常会产生误导。投射也不例外。特别是因为Java是一种动态语言，而C ++却有所不同。

不管您如何执行，所有Java转换都在运行时完成。类型信息在运行时保存。C ++更加复杂。您可以将C ++中的一个结构强制转换为另一个结构，这只是对表示这些结构的字节的重新解释。Java不能那样工作。

Java和C ++中的泛型也有很大的不同。不要过度担心自己在Java中如何执行C ++事情。您需要学习如何用Java方式做事。

Class.cast()在Java代码中很少使用。如果使用它，则通常使用仅在运行时才知道的类型（即通过它们各自的Class对象和某些类型参数）。它仅在使用泛型的代码中真正有用（这也是之前未引入的原因）。

这是不是类似reinterpret_cast，因为它会不会让你在运行任何超过普通投不打破类型系统（即你可以打破泛型类型参数，但不能打破 “真正”的类型）。

C样式强制转换运算符的弊端通常不适用于Java。看起来像C样式转换的Java代码dynamic_cast<>()与Java中具有引用类型的Java代码最为相似（请记住：Java具有运行时类型信息）。

通常，将C ++强制转换运算符与Java强制转换进行比较非常困难，因为在Java中，您只能强制转换引用，而且对象也永远不会发生转换（只能使用此语法转换原始值）。

通常，强制转换运算符比Class＃cast方法更可取，因为它更简洁，并且可以由编译器进行分析以解决代码中的公然问题。

Class＃cast负责在运行时而不是在编译期间进行类型检查。

当然，有一些Class＃cast用例，特别是涉及反射操作时。

自从lambda来到Java以来​​，例如，如果我正在使用抽象类型，我个人喜欢将Class＃cast与collections / stream 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一样，将获得运行时（或代码中有足够的信息作为编译时）异常。因此，在Java中，不使用C类型转换的C ++想法不是一个好主意。

除了消除最常提及的难看的转换警告外，Class.cast是运行时转换，通常与泛型转换一起使用，由于泛型信息将在运行时被删除，并且某些泛型将被视为Object，这导致不引发早期的ClassCastException。

例如serviceLoder在创建对象时使用此技巧，请检查S p = service.cast（c.newInstance（））; 当SP =（S）c.newInstance（）时，这将引发类强制转换异常。不会并且可能显示警告“类型安全：未经检查的从Object到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包含一个数组或嵌套的JSONObjects的情况下（这意味着此处的数据不是原始类型或String），我尝试以此方式调用setter方法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()我能想到的极少数合法用例之一，至少现在您有另一个例子。