7

In Java, operators <, >, >= and <= are not defined for the primitive boolean type. However, the corresponding wrapper class Boolean implements Comparable. That is: true > false is an error, but Boolean.TRUE.compareTo(Boolean.FALSE) > 0 is fine.

How come? Did the language designers change their mind? Why keep the incoherent behavior, then?

Although arbitrary, I can think of advantages to having a total order defined for booleans. Are there any disadvantages?

João Manuel Rodrigues
  • 379
  • 4
  • 8
  • yes, this is how they chose to implement it. not that I see much sense in `>` compiling for primitives... – Eugene Apr 02 '21 at 16:26
  • @Eugene, `>` compiling for primitive `boolean` would make it coherent with `Boolean`. So, why not? In Pascal, boolean is defined as a enumerated type, with arbitrary order `false < true`. One possible use: `A <= B` can be used to mean "A implies B". (Not very intuitive, I know, but I've seen it used so.) – João Manuel Rodrigues Apr 02 '21 at 17:15
  • I didn't sit on the original Java committee that made this decision (to get an authoritative answer, you'd have to ask them), but if I were to speculate, I'd say that sorting Booleans using operators isn't particularly interesting, and since Comparable already exists for Boolean (i.e. there's already a way to do this for those who are so inclined), they probably decided it wasn't worth the trouble. – Robert Harvey Apr 02 '21 at 17:21
  • You can't compare strings in Java using `==` either. (You *can* in C#, but C# has operator overloading built into the language; Java doesn't). – Robert Harvey Apr 02 '21 at 17:23
  • It would be useful to have primitive boolean comparison. In practical coding I used implication numerous times, and have to express it via negation and binary disjunction instead. – Tegiri Nenashi Apr 02 '21 at 17:25
  • it probably all resolves around operator overloads - cause if they allows `>` for `boolean`, people would just scream : "why not just add it there also?". This is how I see it. Disallow it everywhere and be done with it – Eugene Apr 02 '21 at 17:29
  • 2
    "Why was the language designed this way" can't have an objectively verifiable answer until we get an answer from one of the language designers. This will likely just devolve into discussions and opintions. Therefore I vote to close as opinion-based. – Joachim Sauer Apr 02 '21 at 17:34
  • Also note that there's a minor semantic difference between `<` and implementing `Comparable`: supporting `<` implies a less-than relationship and implementing `Comparable` just implies some natural order between instances. It does not state if that order is numeric or something else. – Joachim Sauer Apr 02 '21 at 17:36
  • @JoachimSauer - I agree this is likely to generate poor quality discussion, but I still hope to get an answer from one of the designers. – João Manuel Rodrigues Apr 02 '21 at 18:11
  • 2
    See also [Why Boolean wrapper class implements Serializable interface and Comparable interface ? What is the use of it?](https://stackoverflow.com/questions/13892403/why-boolean-wrapper-class-implements-serializable-interface-and-comparable-inter) . – Andy Thomas Apr 02 '21 at 18:56
  • 1
    I found the original bug that led to adding Comparable as a superinterface to Boolean, and summarized the rationale in an [answer to the duplicate question above](https://stackoverflow.com/a/66924190/202009). – Andy Thomas Apr 02 '21 at 19:21

1 Answers1

2

Programming languages are not mathematical constructs. They are complex projects spanning many years and a lot of different people. As such, they are subjected to opinions, legacy, disagreements, hype cycles, influences of other languages, poor communication, and unfortunately sometimes also to mistakes and stupidity. You could argue that most decisions about a language are in fact arbitrary.

Your question is perfectly valid: why is it like this? Unfortunately without asking people who made the relevant commits how much they can still remember is not really a viable option. So your guess is as good as anybody else's.

It is what it is, but you are entitled to have your own opinion. Sadly, such inconsistencies can be in some cases frustrating to the point when people abandon a language and create a new one. But since computers are physical, limited things, any new language will also be imperfect and opinionated.

If you ask me, having a total ordering on boolean is a good idea - it wouldn't hurt anybody, while it could provide some limited benefit in certain (although very narrow) cases. But there are many more, much much bigger issues with Java. As it stands, I don't think Oracle will risk breaking any existing programs by changing this behaviour.

jurez
  • 4,436
  • 2
  • 12
  • 20
  • "Programming languages are not mathematical constructs." - Yes, they are. – nicomp Apr 02 '21 at 18:22
  • 2
    @nicomp: Of course they are - but on the level of meaningless hardware bits, not on the level of abstraction that we want them to be. Any abstractions we make are leaking - i.e. they have a point where they break. I know because I tried, but feel free to try it yourself if you don't believe. – jurez Apr 02 '21 at 18:23
  • @nicomp No, they are *reducible* to mathematical constructs. But the initial work isn't wholly mathematical in nature. Why is X specced like that? Well, because Alice did it in an afternoon and nobody could be bothered with refining it. Why does Y behave one way instead of another? Bob was very opinionated, the meeting for this was going for much too long and people just agreed, so they can go grab a coffee. Neither of these are mathematical in nature. And they happen a lot more often that you might think. – VLAZ Apr 05 '21 at 09:35
  • To clarify my point - I see the main reason in the fact that computers have limited space and speed. For example, in mathematics (sqrt(2))^2 is exactly 2 while in software there will always be a rounding error, no matter how many decimals you use. Each abstraction will break somewhere, and getting to that point is surprisingly simple (i.e. just take 1000000 times the normal amount of data). In software engineering we are always forced to cut corners, so it's all about trade-offs. It's those trade-offs that break mathematical constructs, or to be precise, make them too complex to be usable. – jurez Apr 05 '21 at 11:26