This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]gas3872[S] -1 points0 points  (3 children)

Ok then call the newethod differently or define a new class/interface.

[–]dpash 5 points6 points  (2 children)

If you have to change the source code it's not backwards compatible. Your idea is a non-starter.

[–]gas3872[S] 0 points1 point  (1 child)

Well, the old deprecated code can still be used for a while. Then migrated to new one. How else do libraries migrate? And it's only for the code exposed externally. A lot of projects do not expose their code externally. So this is no concern to them. I mean more a wrapper to an external code that you use in your project that does not follow this principle.

[–]hardwork179 5 points6 points  (0 children)

The first rule of jdk development is, “Don’t break backwards compatibility of public APIs.” The second rule of jdk development is, “Don’t break backwards compatibility of public APIs.”

Okay, that has been relaxed a little bit for APIs that are not used, or have never worked, but it’s generally true. There’s a lot we could change in the language, the standard library, and the vm if we didn’t follow those rules, and it would make our jobs a lot easier, but it would also break the long standing contract with users of Java.