Java Class.cast() 与 cast 运算符 [英] Java Class.cast() vs. cast operator

问题描述

在我的 C++ 时代学习过 C 风格强制转换操作符的弊端，起初我很高兴地发现在 Java 5 中 java.lang.Class 已经获得了一个 cast 方法.

Having being taught during my C++ days about evils of the C-style cast operator I was pleased at first to find that in Java 5 java.lang.Class had acquired a cast method.

我认为我们终于有一种面向对象的方式来处理转换.

I thought that finally we have an OO way of dealing with casting.

原来 Class.cast 与 C++ 中的 static_cast 不同.它更像是reinterpret_cast.它不会在预期的地方生成编译错误，而是会推迟到运行时.这是一个简单的测试用例来演示不同的行为.

Turns out Class.cast is not the same as static_cast in C++. It is more like reinterpret_cast. It will not generate a compilation error where it is expected and instead will defer to runtime. Here is a simple test case to demonstrate different behaviors.

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 );
        }
    }
}

所以，这些是我的问题.

So, these are my questions.

1. 应该将 Class.cast() 放逐到泛型领域吗?它有很多合法用途.
2. 当使用 Class.cast() 并且在编译时可以确定非法条件时，编译器是否应该生成编译错误?
3. Java 是否应该提供强制转换运算符作为类似于 C++ 的语言结构?

1. Should Class.cast() be banished to Generics land? There it has quite a few legitimate uses.
2. Should compilers generate compile errors when Class.cast() is used and illegal conditions can be determined at compile time?
3. Should Java provide a cast operator as a language construct similar to C++?

推荐答案

我只使用了 Class.cast(Object) 来避免泛型领域"中的警告.我经常看到方法做这样的事情:

I've only ever used Class.cast(Object) to avoid warnings in "generics land". I often see methods doing things like this:

@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) 的唯一用例.

That's the only use case for Class.cast(Object) I've ever come across.

关于编译器警告:我怀疑 Class.cast(Object) 不是编译器所特有的.它可以在静态使用时进行优化(即 Foo.class.cast(o) 而不是 cls.cast(o))，但我从未见过有人使用它 -这使得将这种优化构建到编译器中的努力变得毫无价值.

Regarding compiler warnings: I suspect that Class.cast(Object) isn't special to the compiler. It could be optimized when used statically (i.e. Foo.class.cast(o) rather than cls.cast(o)) but I've never seen anybody using it - which makes the effort of building this optimization into the compiler somewhat worthless.

这篇关于Java Class.cast() 与 cast 运算符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！