“可选操作”在Javadoc中的含义是什么，例如Set＃add（E）？
在用于Set的java文档中时，它在方法规范中说明Optional Operation例如（我强调）
添加（E e）
如果指定的元素尚不存在，则将其添加到此集合（可选操作） 。
可选的含义是什么？
如果我使用除SUN / Oracle之外的JVM，Java的实现可能无法提供此操作？
Set是一个界面。 实现该接口的类不一定需要为可选操作提供实现。
我认为这些可选操作会回到一般的Collection接口，在这个接口中，操作是可选的，对某些类型的集合没有意义。 例如， add是一种在某种只读集合上并不真正有用的操作。 它在Javadoc中明确地拼写出来，因此它成为所有集合类提供的一部分，但是使用它的人知道，鉴于某些集合他们并不确切知道，可能是该方法只抛出UnsupportedOperationException 。
从java.util.Collections文档：
如果此集合不支持该操作，则指定此接口中包含的“破坏性”方法（即修改其操作集合的方法）将抛出UnsupportedOperationException。 如果是这种情况，如果调用对集合没有影响，则这些方法可能（但不是必须）抛出UnsupportedOperationException。 例如，如果要添加的集合为空，则可以（但不是必须）在不可修改的集合上调用addAll（Collection）方法抛出exception。
请注意，那里描述的许多方法都不是可选的。
可以说，Java Collections Framework并不完美; 这可能是抚养其（微小）头部的不完美之一。
在JavaDoc中将接口方法指定为可选的意味着实现此接口的类不一定必须实现该方法。 相反，他们可以例如抛出exception。
更具体地说，接口方法在JavaDoc中是可选的并不意味着它是特定于实现的行为。 该类的每个具体实现都将指定它是否实现它。 查看HashMap类，它包含add操作，并没有将其指定为可选。 因此，Java库的每个实现都必须为其HashMap类包含此方法的实现。 TreeMap等也是如此。
将此操作声明为可选的原因可能是因为某些集合在概念上可能是不可变的，例如Collections.unmodifiableSet返回的集合。