我知道@SuppressWarnings("unchecked")注释可以用来抑制编译器警告，当泛型没有按照它们的意图精确使用时。我理解，从纯粹主义的角度来看，人们几乎不应该使用这些注释，而应该重构代码，以便没有警告。
但那让我思考。
是否有任何经验法则规定当安全使用这些注释时（而不是“不安全”使用会导致调试地狱）？如果是这样，他们是什么，以及他们在什么类型的情况下发生？
提前致谢！
答案 0 :(得分：1)
有两个主要方面我经常使用这个注释（我会说，正确）：
答案 1 :(得分：1)
如上所述，添加这些内容的唯一真正原因是当您使用旧版Java的库时，或者只是不使用Generics时。在这种情况下，我通常会选择添加注释，但我理解那些不注释的参数。
有时，可能无法重构整个系统以符合泛型标准（它应该在完美的世界中）。
我遇到的其他情况是，在某些过程中使用生成的代码时，这不会生成泛型......有时你可以改变生成代码的方式，有时你不能。
任何时候你都可以在没有SupressWarnings的情况下解决问题......这样做！ ：d
答案 2 :(得分：1)
如果它是你的代码并且你知道将通过该方法传递的所有类型，它本质上并不“不安全”，因为Java并不总是具有泛型 - 它的形式更糟糕。它更多的是你是否确定你的代码能够正常工作的问题。
我尽可能多地关注这些问题，但是在使用第三方库时，有时它只需要注释即可忽略。示例：未选中Hibernates list()方法，因此Eclipse会抱怨。我知道我要回来的物品，所以我可以忽略它。
答案 3 :(得分：0)
我的强迫症选择寻找这些并尽可能消除它们。我选择使用这些警告的唯一原因是当我链接到不使用参数化集合，迭代器，类等的库时
但是，我故意不要添加@SuppressWarnings，因为我有一个很好的小问题列表，提醒我需要做些什么......当我有时间重写外部库（或发送电子邮件和开发者）让他们这样做:)）
答案 4 :(得分：0)
“Effective Java 2nd Edition”对该主题进行了非常好的讨论（第5章，第25项及其后）：