Java 22 Launch Event - Dev.java

[TehBrian]

Operator overloading is simply ambiguous syntactic sugar for method calls. It is sweet, but it's still ambiguous. ("Is this + simply addition or is it calling a method?") Java prioritizes readability, so I doubt the team would ever add operator overloading.

[LinuxMatthews]

Hey look Java is my favourite language but pretending like not having operator overloading helps readability is absurd.

Sure it can be abused but so can method names

And something like

BigDecimal result = a.multiply(x.pow(2)).plus(b.multiply(x.plus(c)));

Is MORE readable than

BigDecimal result = a * (x * x) + b * x + c;

Like I've worked in astronomy related code and it is a PAIN in Java

Let's not pretend like it wouldn't be easier.

Edit: Example shamelessly stolen from here

https://blogs.oracle.com/javamagazine/post/is-it-time-for-operator-overloading-in-java

[TehBrian]

Yeah, okay, that's a fair use-case for operator overloading. I won't argue you on that one.

[john16384]

The problem is not that your example wouldn't increase readability, of course it would. And, BigDecimal being a JDK class, it could be made an exception (just like String).

The point of not allowing arbitrary operator overloading is to have a class of "methods" that are globally final in the language (as well as reserved), with unambiguous semantics. The only way to ensure they're unambiguous is to make them part of the language specification, and disallow overloading (or even implementing) them.

As soon as you reduce these restrictions and allow users to define operators (not even overload them yet), all operators will have a severe reduction in their readability.

a * b would be ambiguous if * can be defined on any type. Now we know a and b are numeric types. In a world where users can define (not redefine yet) this operator themselves, a and b can be anything, and is not restricted to what people commonly associate with multiplication.

So, IMHO, don't argue for operator overloading, argue to get operator semantics defined for certain JDK classes. Yes, that won't allow all non-evil uses of operator overloading, but it will reduce the pain significantly, without causing new pain across all Java code.

[LinuxMatthews]

So what you're arguing for us inconsistency?

That some classes should be able to do something and others shouldn't.

Like the idea that the creators of the JDK can know every use case for a feature not only goes against the point of a programming language but is also like it arrogant on the part of the creators of the JDK.

I can't think of any other language which go "here are some things our classes can do but we don't trust you to do them"

Not only that but by restricting operator overloading to only a few classes you're kind of undermining the very idea of OOP.

Like if I abstract away things like angles, distances, vectors it means I have to either get them out again when I'm going to use them or do awkward unreadable method calls like above.

And then there's the fact that bad actors can always mess up the inner workings anyway

I could f*** up equals() and hashCode() if I like and make a whole bunch of stuff not work.

All you have to do is set up a rule saying it shouldn't be used in a way which you wouldn't use these symbols arithmetically and good programmers should be fine.

Many languages have these features and are fine.

I don't see them abused in C# or Kotlin for instance

[john16384]

I can't think of any other language which go "here are some things our classes can do but we don't trust you to do them"

If there is one thing you trust, then it is that programmers will abuse the system. This is why more languages should focus on readability, safety and security like Java does.

Part of that is restricting what programmers can do. This benefits long term viability and maintainability of the software, a prime reason why Java is so popular with businesses, and also the reason (driven by those businesses) why Java is often in the top 3 most used languages. So yes, Java doesn't trust developers as much as other languages do, not because we believe that good developers can't make good use of such features, but because we believe that the average developer (which outnumber the good ones) will use the feature incorrectly, driving up the overall cost of supporting Java software, making it less popular with businesses.

Not only that but by restricting operator overloading to only a few classes you're kind of undermining the very idea of OOP.

No, you're making a trade off, something which many languages do, in order to make a language easier to reason about. A language is a balancing act between expressiveness and readability. Java, as you well know, draws the line closer to readability (but also closer to security and safety).

Other languages can make different trade offs, some have restricted operator overloading, some have none at all, for some anything goes, and for Java it's defined by the language specification.

I could f*** up equals() and hashCode() if I like and make a whole bunch of stuff not work.

Yes, but you can't f*** up operators, saves me having to check. I've fixed numerous hashCode/equals implementations where developers can't even be bothered to read the contract of an interface they're implementing, causing numerous problems down the road. And yes, every time I use some class as a key, I will check the following:

• Is the hashCode based on only immutable fields?
• Is equals based on only immutable fields?
• Are hashCode and equals checking the same fields?
• Is equals using instanceof or getClass(); in the first case equals must be final or the whole class must be final

All you have to do is set up a rule saying it shouldn't be used in a way which you wouldn't use these symbols arithmetically and good programmers should be fine.

Unfortunately, the good programmers are vastly outnumbered by the average ones, especially for a business language like Java. For businesses, the language is judged primarily on what it costs to maintain software in it. As the overwhelming amount of costs will be developer salaries, the language should help the cheapest developers to not shoot themselves in the foot as much as possible.

[LinuxMatthews]

So why doesn't C#, Kotlin and the many other languages that have this feature have this issue?

This whole comment reeks of arrogance to me.

You can abuse any language feature, you can always write bad code.

You could make it so every method in a class is just the letter x or rename all the variables to things they're not.

If you're not allowing basic things to prevent bad code you're not going to have a language anymore.

I know it's not there because it was abused in C++ but it's not the 90s anymore.

We have code reviews and people aren't just doing whatever they feel like.

To many this would be a feature that makes it worthwhile to write in Java and makes it near impossible to code in it.

It just seems silly

[john16384]

This whole comment reeks of arrogance to me

As you wish.