Clashing method names with `java.util.collections.*` about kotlinx.collections.immutable HOT 3 CLOSED

There were some problems in Kotlin 1.0.3 handling this situation, but thanks to @dzharkov they all are fixed now in master branch and those fixes might already be backported to 1.0.x branch.
So currently koltinx.collections.immutable could be compiled only with the fresh Kotlin build, but later we plan to switch to more stable compiler version, like 1.1-M2 or even 1.0.4.

We're aware that our modification methods hide the methods of java.util.Collection with the same name, but since it's allowed by JVM we do not expect it would cause problems when being used from Kotlin.
And our tests also show these immutable collections could be used from Java, see ImmutableListJavaTest.java for example.

If you have a concrete example where such name clash would cause problems, please share it.

from kotlinx.collections.immutable.

I could imagine two situations where the name clash could have consequences.

First is rather interesting effect, though unintended: one cannot implement both MutableCollection and ImmutableCollection in the same class. Though it seems not so bad, considering such implementation makes no sense.

Second is like the first one but from Java side: an ImmutableCollection could not be implemented in Java, because it would ultimately conflict with the java.util.Collection interface which has all methods as MutableCollection in Kotlin. This is a problem, however it can be easily worked around by implementing such collections in Kotlin :)

from kotlinx.collections.immutable.

Okay, so it is a deliberate decision. Seems legit.

one cannot implement both MutableCollection and ImmutableCollection in the same class. Though it seems not so bad, considering such implementation makes no sense.

Actually, it may well make sense. There are data structures that can be an efficient implementation of both an ephemeral and persistent collection with useful properties, e.g. a segment tree or an implicit treap. It is all a matter of usage pattern, not the structures themselves.
But, of course, you can always resolve this problem using delegation.

Second is like the first one but from Java side: an ImmutableCollection could not be implemented in Java

Actually, it seems that you can as long as you don't try to override the Collection's base methods. I just tried it. Still don't get how it's possible (java 8 default methods hidden somewhere in Kotlin's Collection interface?).

from kotlinx.collections.immutable.