Diamond运算符不能总是在Java 8中使用。最初的改善Java 8推理的计划（JEP
101）有两个目标：
- 在方法上下文中添加对方法类型参数推断的支持
- 添加对链式调用中方法类型参数推断的支持
仅第一个实施。从JEP借用该示例，请考虑以下类：
class List<E> { static <Z> List<Z> cons(Z head, List<Z> tail) { ... }; E head() { ... }}在Java 8中，改进的方法上下文推论允许以下内容进行编译。使用Java 7，它将因错误而失败
expected List<Integer>, foundList<Object>
List<Integer> l = List.cons(42, new List<>());
但是，需要推理链式调用的示例仍无法在Java 8中使用：
Integer i = new List<>().head();
JSR 335的
D部分包含有关Java 8为什么放弃链式表达式推理的提示：
允许推理到“链”已经引起了一些兴趣：在a（）。b（）中，将类型信息从b的调用传递到a的调用。由于部分信息必须在两个方向上传递，这为推理算法的复杂性增加了另一个维度。它仅在所有实例化（例如List）的a（）返回类型的擦除固定后才起作用。由于无法轻松导出目标类型，因此该功能不太适合多表达式模型。但也许有其他增强功能可以在将来添加。
还有一些更人为的例子，其中不能使用钻石。
如果算错了，那么jdk8u25之前的javac不会编译它。（请参阅JDK-8029002）
class Test { class C<T extends C<T>> {} void m() { C<?> i = new C<>(); }}error: incompatible types: cannot infer type arguments for Test.C<> C<?> i = new C<>(); ^ reason: inferred type does not conform to upper bound(s) inferred: Test.C<CAP#1> upper bound(s): Test.C<Test.C<CAP#1>>,Test.C<CAP#1> where CAP#1 is a fresh type-variable: CAP#1 extends Test.C<CAP#1> from capture of ?新类型的推理实现还存在一个性能问题（JDK-8051946），该问题可能会影响使用菱形运算符的代码。如果使用菱形运算符，下面的示例将花费几分钟的时间进行编译。
class Test { <T> T and(T a, T b) { return null; } class C<T> {} void g(String s) {} void g(Object s) {} void m() { g( and( and( and( and( and( and( and(new C<>(), new C<>()), new C<>()), new C<>()), new C<>()), new C<>()), new C<>()), new C<>())); }}
