为何找不到Java 7中的警告
Java7的这个新特性改变了警告的对象。构建这些类型毕竟有破坏类型安全的风险，这总得有人知道。但API的用户对此是无能为力的，不管doSomething()是不是干了坏事，破坏了类型安全，都不在API用户的控制范围之内。
真正需要看到这个警告信息的是写doSomething()的人，即API的创建者，而不是使用者。所以Java7把警告信息从使用API的地方挪到了定义API的地方。
过去是在编译使用API的代码时触发警告，而现在是在编译这种可能会破坏类型安全的API时触发。编译器会警告创建这种API的程序员，让他注意类型系统的安全。
为了减轻API开发人员的负担，Java7还提供了一个新注解java.lang.SafeVarargs。把这个注解应用到API方法或构造方法之中，则会产生类型警告。通过用@SafeVarargs对这种方法进行注解，开发人员就不会在里面进行任何危险的操作，在这种情况下，编译器就不会再发出警告了。
类型系统的修改
虽然把警告信息从一个地方挪到另一个地方不是改变游戏规则的语言特性，但也证明了我们之前提到的观点——Coin项目曾奉劝诸位贡献者远离类型系统，因为把这么一个小变化讲清楚要大费周章。这个例子表明搞清楚类型系统不同特性之间如何交互是多么费心费力，而且对语言的修改被实现后又会怎么影响这种交互。这还不是特别复杂的修改，更大的变动所涉及的内容还会更多，其中还包括大量微妙的分支。
最后这个例子阐明了由小变化引发的错综复杂的影响。我们对Coin项目中改进的讨论也结束了。尽管它们几乎全都是语法上的小变化，但跟实现它们的代码量相比，它们所带来的正面影响还是很可观的。一旦开始使用，你就会发现这些特性对程序真的很有帮助！
小结
修改语言非常困难。而用类库实现新特性总是相对容易一些，当然并不是所有特性都能用类库实现。面对挑战时，语言设计师可能会做出一些比他们的预想更轻微、更保守的调整。
现在，我们该去看看构成发布版本更重要的东西了，先从Java7中某些核心类库的变化开始。我们的下一站是I/O类库，那里可以说是发生了天翻地覆的变化。在此之前，希望你已经掌握了Java之前的版本处理I/O的方法，因为Java7中的这些类（有时候被称为NIO.2）是构建在之前框架基础之上的。
如果你想看到更多关于TWR实战的例子，或者想要了解最新、高性能的I/O类，可以参考毛票票其他相关文章。