是否可以在不破坏 Java 的情况下向 Comparable 添加默认方法？

Question

I was thinking of proposing a feature request to add default methods called:

default boolean greaterThan(T o) {
    return compareTo(o) > 0;
}

default boolean smallerThan(T o) {
    return compareTo(o) < 0;
}

default boolean atLeast(T o) {
    return compareTo(o) >= 0;
}

default boolean atMost(T o) {
    return compareTo(o) <= 0;
}

to the Comparable interface as it would make the code much more readable - in my opinion.

However, I'm wondering if that would break code. Is there any code such as Lambda's that would break if we add default methods?

If I read this correctly I would assume that Lambda's would at least remain working, as long as they won't try to call the new methods, but I'm not sure. And I don't know if there could be any (obvious) other issues.

Please, no discussion about the possible feature request itself.

Answer 1

Unfortunately, @BasilBourque's answer is misleading, even though it quotes useful entities.

There is no way this feature will be introduced by way of a subinterface. SortedMap/NavigableMap is not applicable: The default mechanism was not around when NavigableMap was introduced!

At this point, it may be worthwhile to introduce some or all of the methods in NavigableMap as default methods in SortedMap , with implementations that work on sortedmaps and which will automatically end up getting overridden by any Map impls that implemented NavigableMap already (as they have overridden all of those in their impl).

However, it means that 'Hey, look at NavigableMap which is analogous to SortedMap just like what you want to do to Comparable' is a misleading argument : Your proposal involves adding default methods. That just wasn't on the table back then.

In the end what you want is 'almost, but not entirely, backwards compatible'. Oracle/Java Lang Architects tend to say that 'java does not break backwards compatibility' but this is a gross oversimplification and a borderline lie. If you ask a little further they will eventually admit that this is not true: The heart of the matter is that java weighs the cost of any backwards break (how likely is it, and what happens to code that did break it? If it silently still compiles and runs but does the wrong thing, that's horrible, if it is a trivial update that a refactor script can automatically apply every time, that's great - and then mix in the odds any given codebase stumbles on it, and you have an idea of 'cost'), vs the benefit of it.

The costs are very minor here. It is extremely unlikely any code base would break. However, if you want to actually propose this feature, it would help a lot to do some research and try to think of any library (or if you can't, look at the top 100 lists which various folks blog about, analysing eg github java projects as source material) to go through a bunch to try to see if the thing that happened with .isEmpty would happen with these methods.

Then, there is some bad news: Proposing a java feature is exceedingly unlikely to succeed. For some perspective, as author of Project Lombok, someone who's spend many hundreds of hours reading mailing lists like lambda-dev, who has contributed a large part of the actual lambda syntax and conceptual basis, and has held conversations with multiple Java Language Architects at some length (mostly at java conferences), I've sent in a proposal which included a full patch for java itself, and all due updates needed for the JLS, which didn't break backwards compatibility at all, and it never got anywhere. Not even so much as a JEP.

Last time I spoke to an Oracle engineer they did promise that things are a little bit better now, but that doesn't go particularly far: I don't know of any java feature around or on the horizon that was sourced by an outsider that got kicked straight to a JEP and got anywhere near the foreseeable horizon of java features in the past 10 years. From time to time someone (usually Joe Darcy or Alex Buckley) runs a project to 'add a bunch of small convenient language changes', such as Project Coin (that was 11 years ago, oof). The second take on this is Project Amber , which I think is meant to be a more continuous project vs. coin which had a specific short-lived timespan.

The route to get this into java would presumably go through amber.

Answer 2

As commented by Johannes Kuhn , Stuart Marks documented a case where adding the CharSequence.isEmpty() default method to Java 15 broke a third-party library.

So, given the historic priority to make newer versions of Java maximally backward-compatible with existing apps, the better approach is to define a new interface. The new interface would introduce your new methods. In theory the old interface might eventually, after a very long time, be marked deprecated to suggest phasing out the old for the new. In the meantime, existing code would not be disturbed while new code could take advantage of the new ideas.

This was done, for example, in the Map interface. The sub-interface SortedMap arrived with Java 1.2 (aka Java 2). Years later, in Java 6, came the idea to extend that interface with additional methods. But revising SortedMap runs the risk of disturbing existing implementations within the bundled Java libraries as well as breaking third-party implementations. So they chose to instead define a new interface NavigableMap . They made the newer interface NavigableMap a sub-interface of SortedMap .

NavigableMap is really just the “2.0” version of SortedMap . As far as I know, there is no reason why any implementation would not want to support the larger suite of methods rather than the fewer found in SortedMap . So, sure, it would be nice to have had only a single such interface rather than two, but c'est la vie .

Here is a graphic table I made showing the various implementations of the Map interface bundled with Java 11. You can see how the interfaces SortedMap and NavigableMap live side-by-side.

I wholeheartedly support your idea of effectively extending Comparable with those particular methods (good naming, too, btw). But I believe your proposal would only fly as a new sub-interface of Comparable .