CODEWITHSUNDEEP
javainterface
jinge
jinge

Reputation: 865

Is Interface API always constant?

Such as java.util.Set<E>, is it guaranteed to be consistent? "Consistent" means that the author will never add or delete or modify the current interface methods. So that my classes implemented it can always work.

In fact, I am thinking about the risks when I use "Composition" instead of "Inheritance". (Effective Java Item 16) Once Set API changes, the code will broken.

Upvotes: 0

Views: 66

Answers (2)

ajb
ajb

Reputation: 31689

I wouldn't worry about it. Oracle is a business. If they made a change to one of their common APIs that caused tons of programs to stop working, it would be a big black eye for them and damage their brand. They're not going to do that.

If they do plan to make an incompatible change, I believe they would start by marking as "deprecated" any method that they're planning to remove in a future release. There's also a @Deprecated annotation, which will cause compilers and IDEs to generate warnings. This should give users of the feature fair warning that they will need to make changes eventually. I don't know how long users typically have before they must make a change, but it seems to me that some Java features have been marked as deprecated for several releases. (Exception: raw generic types are documented as something that could disappear. So if you declare an object to be a Set, as opposed to a Set<SomeType> or Set<?>, that could break in a future version of Java.)

A caveat: this applies only to properties that are documented in the API. In the case of Set, in particular, the documentation says that if you iterate through a set (e.g. for (element : mySet)), the order is undefined unless the actual set is an implementation that says the order is defined. In particular, it will be undefined for a HashSet. That means that if you write code, intentionally or inadvertently, that only works if the results come out in a certain order, your code could break in the next release.

EDIT: As to whether methods could be added to an interface: Note that adding methods doesn't break normal code that uses already-provided objects that are instances of the interface, but it could break code that implements the interface. For interfaces that are provided mainly so that users' code can implement it (e.g. Runnable, functional interfaces), adding methods (other than default methods) could break a lot of code, so I'd assume they would avoid adding methods for the same reason. (If they wanted to add a method, they could define a new subinterface.) For the collection classes like Set, it's a bit less clear, since it's more normal for code to use one of the implementations Java already provides; developing one's own implementation seems fairly uncommon. Still, contrary to my first version of this answer, I wasn't able to find any cases where a non-default method has been added to one of those interfaces.

Upvotes: -1

Stephen C
Stephen C

Reputation: 718788

Is Interface API always constant?

I assume that you are asking if the Set API can ever be changed in an incompatible way.

The only people who can actually guarantee that are Oracle.

I have not seen any guarantees (in writing) from Oracle, but based on past history, there is ZERO chance that they would alter the Set API in a way that would impact binary compatibility for user code.

In short: don't worry about it. Certainly for any of the standard interfaces1 in Java SE.

1 - The internal interfaces are a different matter; e.g. any APIs in the sun.* package tree. However, if you use them that's one of the risks that you are taking. Beware!

Upvotes: 3

Related Questions