将一个实例转换为一个糟糕设计的类型。尽管如此，在某些情况下别无选择。因此，从第一天起，执行此操作的能力就成为 Java 的一部分。
我认为 Java 8 需要稍微改进这种古老的技术。
静态铸造
Java中最常见的强制转换方式如下：
Object obj; // may be an integer
if (obj instanceof Integer) {
Integer objAsInt = (Integer) obj;
// do something with 'objAsInt'
}
这使用了 instanceof 和 cast 运算符，它们被嵌入到语言中。实例被转换为的类型，在本例中为 Integer ，必须在编译时静态已知，所以我们称此为静态转换。
如果 obj 不是 Integer ，上述测试将失败。如果我们无论如何都尝试转换它，我们会得到一个 ClassCastException 。如果 obj 为 null ，则它无法通过 instanceof 测试但可以强制转换，因为 null 可以是任何类型的引用。
动态铸造
我很少遇到的一种技术是使用 Class 上与运算符对应的方法：
Object obj; // may be an integer
if (obj instanceof Integer) {
Integer objAsInt = (Integer) obj;
// do something with 'objAsInt'
}
请注意，虽然在此示例中，要转换为的类在编译时也是已知的，但不一定如此：
Object obj; // may be an integer
if (obj instanceof Integer) {
Integer objAsInt = (Integer) obj;
// do something with 'objAsInt'
}
因为类型在编译类型时是未知的，所以我们称之为动态转换。
错误类型实例和空引用的测试和转换结果与静态转换完全相同。
由 vankarsten 在 CC-BY-NC 2.0 下 发布 。
在 Streams 和 Optional 中投射
现在
转换 Optional 的值或 Stream 的元素是一个两步过程：首先我们必须过滤掉错误类型的实例，然后我们可以转换为所需的类型。
使用 Class 上的方法，我们使用方法引用来完成此操作。使用 Optional 的例子：
Object obj; // may be an integer
if (obj instanceof Integer) {
Integer objAsInt = (Integer) obj;
// do something with 'objAsInt'
}
我们需要两个步骤来完成这件事没什么大不了的，但我觉得这有点尴尬，而且比必要的更冗长。
未来（也许）
我建议在返回 Optional 或 Stream 的 Class 上实现转换方法。如果传递的实例是正确的类型，将返回一个 Optional 或一个包含 cast 实例的单例 Stream 。否则两者都是空的。
实现这些方法很简单：
Object obj; // may be an integer
if (obj instanceof Integer) {
Integer objAsInt = (Integer) obj;
// do something with 'objAsInt'
}
这让我们可以一步使用 flatMap 进行过滤和转换：
Object obj; // may be an integer
if (obj instanceof Integer) {
Integer objAsInt = (Integer) obj;
// do something with 'objAsInt'
}
错误类型或空引用的实例将无法通过实例测试并导致空的 Optional 或 Stream 。永远不会有 ClassCastException 。
成本和收益
剩下有待确定的是这些方法是否会发挥自己的作用：
- 有多少代码可以实际使用它们？
- 它们会提高普通开发人员的可读性吗？
- 节省一行值得吗？
- 实施和维护它们的成本是多少？
我会用 不多 ， 一点点 ， 是的 ， 低 来回答这些问题。所以它接近于零和游戏，但我相信其中有一个小但不可忽略的好处。
你怎么认为？您是否看到自己在使用这些方法？