Disclaimer: this is not about this case (while error sounds as same): class inherits unrelated defaults for spliterator() from types java.u
This is simply a bug. It turns out that the bug starts in the specification, and then spills over into the implementation. Spec bug is here: https://bugs.openjdk.java.net/browse/JDK-7120669
The constraint is perfectly valid; it is clearly possible that there exist types T that extend both I1 and I2. The problem is how we validate the well-formedness of such types.