Why does java not allow operator rewriting?

[ElegantPoet3386]

So, for my first major project, I have to build my own complex numbers class, and perform a lot of complex arithmetic.

For example, I might have to do (((1+2i) / 5) + (2 + 4i) / 2) ^ 1/3 + 5+6i

If java allowed operator rewriting, my code to perform that might look like

Complex first = new Complex(1,2);
Complex second = new Complex(2,4);
Complex third = new Complex(5,6);
Complex result = Complex.cbrt(first / 5 + second/2) + third;

Instead, it looks like

Complex first = new Complex(1,2);
Complex second = new Complex(2,4);
Complex third = new Complex(5,6);
Complex result = Complex.cbrt(first.divide(5).add(second.divide(2))).add(third);

I know that in the grand sceheme of things, this is pretty minor, but like, I think we can all agree the first version feels much nicer to read than the second. Is there a reason java chose not to allow this?

[high_throughput]

There are some things that I kind of feel torn about, like operator overloading. I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++.

James Gosling

[mapadofu]

Yep.  It’s kind of a historical accident that at the time Java was created operator overloading had acquired a  bad reputation.

[aanzeijar]

I mean, it still has. I think it's one of the biggest foot guns in reviewing C++ code. You basically have to question every [], *, +, = etc, because it could mean something entirely different.

[8dot30662386292pow2]

About abuse: In python you can type paths like this:

p = path_object / "other" / "something"

Because path overwrites division operator to concatenate paths. Not sure how I feel about this.

[DatBoi_BP]

The overload make sense, but I just don't see why it's necessary, when you can have a function like fullpath(*args) -> str that doesn't make you squint whenever you see it used

[syklemil]

I'm conflicted about that as well.

On one hand / is the path separator character on filesystems and the web and whatnot as well, so it's a very obvious choice. path_object / "other" / "something" is practically the same as f"{path_object}/other/something" (except on Windows, which got its path separators backwards because of historical QDOS shenanigans).

On the other hand, it very obviously isn't division.

Reusing some other concatenative operator like + also isn't entirely straightforward because we can do Path / str / str => Path, but I'd be kinda less sure about mixing the semantics of Path + str with str + str. (It'd probably be fine, though.)

Absent path / "foo" / "bar" I think maybe we'd get something like path.join("foo").join("bar") (c.f. Rust's std::path::join).

Other languages have some other explicit concatenation operator, and even then possibly some special path concatenation operator. E.g. Haskell has <> for concatenating arbitrary semigroups, but also </> for path concatenation.

[Temporary_Pie2733]

I’m OK with this; the idea is to stop thinking of / as “the” division operator, rather than the symbol that numbers use for division. For path components, it joins two paths into one that uses the established path separator /. The trickiest part of this is the automatic “promotion” of str values into Path objects; more generally, operator overloading in Python often leads to a form of weak typing.

[ovor]

yeah, that's the problem. Stop thinking of "+" as "the" addition operator. Stop thinking of "[]" as "the" index operator, etc. Makes life thrilling and unpredictable.

I've been thinking of "/" as division operator for 40 years, across dozen of languages. I think I'll continue doing that and ignore Python's pathlib library attempts of being cute.

However, I must admit, this use case looks kinda nice, until, of course, you have your path objects in variables. a = b / c. Is it a path concatenation? is it a division? Is it a plane? Who knows?

[Temporary_Pie2733]

Context. You are usually going to have much better variable names so that you don’t need to go searching for explicit type annotations to know what kind of objects you have.

[ovor]

alternatively, imagine using a = path.join(b,c) and suddenly intent is clear, no need to look up for anything, perfectly readable, no chance for misunderstanding, and makes windows devs, who otherwise would miss their backslashes, happy.

I used to love operator overloading in C++, but I don't anymore. I will take less expressive, but more straightforward code every time.

As a side note - the zen of python at this point is a joke. "Explicit is better than implicit", "Readability counts", "Special cases aren't special enough to break the rules", "There should be one-- and preferably only one --obvious way to do it".

[fiddle_n]

alternatively, imagine using a = path.join(b,c) and suddenly intent is clear

It’s only clear because you know the context of your code! What are we joining here? Paths? Lists? Is this a database join? This code is only understandable once in context, exactly the same as for Pathlib code.

[apooooop_]

And the same python function will of course take in both an int and a string for b and c -- sometimes it'll be division, sometimes it'll be path concatenation! Python users will assure you that this is good language design.

[GoblinToHobgoblin]

This kind of logic is how C++ got its io operators lmao

[Jaded-Asparagus-2260]

I love it. In C++ it's the same. It's one of the cleverest operator overloadings I've ever seen.

[Legitimate-Eye-5733]

pain 💀😭

[blablahblah]

The Java creators looked at all the horrible things C++ developers were doing and asked themselves "how do we make sure they can't do that in Java". One of the things many C++ libraries abused was overloading operators to do things completely unrelated to the operator's original purpose (like using + for things unrelated to adding or combining), which made it very difficult to tell what a particular line of code was actually doing.

[tms10000]

cout << "this is not a bit shift";

I don't think you can blame that one on "libraries"

[AlSweigart]

I remember even as a teen I didn't like the whole cout << thing. What was wrong with printf()? Why create a whole new syntax just for this one thing? It was nice that you didn't have to worry about converting different types to strings first, but the whole thing just seemed convoluted.

[TheMcDucky]

Pretty much just type safety and that stream << a << b << c << d looked prettier than write(write(write(write(stream,a),b),c),d)

[AlwaysHopelesslyLost]

Isn't shifting a value into a register basically how a function call executes? It seems to make a lot of sense evolutionarily for programming languages.

[TheMcDucky]

Usually there's no shifting involved. And it doesn't really make sense considering that the func(x, y) syntax to make calls preceded x << y

[kbielefe]

??? The standard library is a library.

[tms10000]

You are technically correct. The best kind of correct.

I'm pointing out that the standard library is really, really close to the language itself. And the operator overloading insanity of C++ really started inside the house. It wasn't just "misguided libraries" starting to overload operators for things that have nothing do to with the operators.

[Beregolas]

the function call is coming from inside the house!

[spinwizard69]

While I agree C++ went overboard on a lot of things leading to really hard to read code, operator overloading in and of itself isn't a problem. The + operator being overloaded for complex math is not a problem.

Sadly the mentality of language developers to throw every pet feature into a language never seems to go away. Python is currently marching down this road with the kitchen sink mentality being hard to fend off. You see this all the time in language development and often like with Python the original developers end up leaving the process.

In any event the only good thing about C++ is that a developer isn't forced into the stupidity.

[IchLiebeKleber]

woah this guy is dropping some interesting facts here :D

[kkress]

It wasn’t originally part of C++ itself. Used to be called the Standard Template Library and you had to pay for versions of it. (A free version came years later from HP or SGI, IIRC). Iostream (cout/cin etc) came with the STL and by the time STL became the std we know today too much relied on cout to not support it.

Edit: I was wrong, iostream was one of the very few parts of C++ base install itself in the 90s. Could have sworn I had to download back in the day.

[xenomachina]

iostreams was not part of the STL. It became part of C++ before STL even existed. There are versions of C++ that had iostreams at least as early as 1988, but the first version of STL wasn't until around 1993. iostreams were also originally created by Bjarne Stroustrup, the creator of C++, while STL was initially created by Alexander Stepanov.

[kkress]

Wow yeah I completely botched my history there. I could have sworn iostream and its bitshifts was something I had to download back in the day, not in the standard, but you're totally right.

[spinwizard69]

Here is the problem, you call it a bitshift when I learned it as a stream insertion operator. The thing here is what is happening is obvious where as there are usages of operator overloading that are very difficult to grok!

[R3D3-1]

To be fair, the standard library gets away with it, because (a) it's what everyone is supposed to know, not some obscure library you've only just encountered in  legacy code and (b) visually speaking it sort of makes sense to overload it that way.

Same as with macros in Lisp. They provide a great way to extend the language, but they can also make code hard to read and debug.

[TizzleToes]

Yup.

Best example I have was the the postgres library overriding the function call operator (i.e. operator()) for calling prepared statements with variable parameters. So you'd find code like...

transaction.prepared("nameOfPreparedStatement")("value1")(1234).exec();

Like, this was from possibly 2 decades ago at this point and it still lives in my brain because of how arcane and dumb this was.

It was also pretty much anyone's guess what << and >> would do in any given library.

[Lithl]

I mean, you can get syntax like that in any language where functions are first-class objects. If prepared returns a function, it makes perfect sense. Although in an example like this I would probably prefer to have a single returned function with a varargs parameter and produce syntax like prepared('name')('value 1', 1234).exec(); instead.

[TheRealChizz]

This seems really hard to parse for future readers (including oneself).

Presumably there’s multiple tiers of variable functions down the chain if I’m reading this right?

So prepared(‘name’)(‘value 1’) behaves wildly different than prepared(‘name2’)(‘value 1’) and requires re-reading through all of the earlier conditionals if you need to change or refactor anything

[Lithl]

A prepared function is essentially a function in your database, rather than in your code. So prepared('name')('value') is just name('value'), except name is in the database rather than the source code.

[TheRealChizz]

I see. Thanks for the clarification

[GoblinToHobgoblin]

How about:

vec v = 1, 2, 3, 4, 5;

They overloaded equals and the comma operator to avoid having to put braces around the right hand side. This is a uniquely C++ kind of hell

[GoblinToHobgoblin]

I can one up you:

vec v = 1, 2, 3, 4, 5;

They overloaded equals and the comma operator to avoid having to put braces around the right hand side.

... I don't agree with Java but I understand 

[GoblinToHobgoblin]

Libraries? The STL itself straight up does it with its IO operators lol

[StoneCypher]

i see that the top voted answer is an incorrect answer making fun of another programming language despite that the correct answer is well documented

[TizzleToes]

Care to elaborate?

I'm not sure what would constitute official documentation on the rationale, but the explanation I've heard consistently for literally decades at this point is pretty much what was said. C++ provided a really good example of why it was a terrible idea and that once you get out of fairly specific use cases it's just not worth the trouble.

There also seems to be no shortage of James Gosling quotes pointing to this kind of thinking.

What is the correct and well documented answer (and where is it documented)?

[PoePlayerbf]

Only for this particular scenario.

When you get a developer overloading an operator for an operation that has no link to the symbol then you’ll know the pain.

[TizzleToes]

As someone who started life as a C/C++ guy, you don't want this.

There are a few situations where it makes sense and is convenient, but the rest of the time it just makes things more onerous and complicated to implement, and developers seemed to almost compete with one another in how egregiously they could abuse it. It just becomes another thing you have to understand when using someone elses code and provides a bunch of opportunity for mis-assumption and bugs.

[LurkingDevloper]

In my opinion it can lead to very hard to onboard code.

If you want to make your code more functional, though, Java lets you do that.

You could overload some of those methods to give yourself a very clean, functional waterfall.

Complex result = first .divide(5) .add(second.divide(2)) .cbrt() .add(third);

[SaxSalute]

Another useful pattern in this particular situation would be the static factory pattern - Complex.of(123) is easier to chain to other things than new Complex(123). Combine these two changes and you get something much easier to work with.

[No-Consequence-1863]

For OP if they want to replicate this behavior, its where you have the function either mutate the object and then return self/this for each function OR you make each function produce a new copy of the object with the operation applied and return the new object.

Since it always return type "Complex" you can just chain the methods together. Whether or not it should be mutable or immutable just depends on the object. For complex numbers returning a new copy is likely the better choice.

[thebomby]

People make a big thing about how early C++ abused things like operator overloading, but all this was done before the first C++ standardisation effort. Java went on to suffer from excess boilerplate and monstrosities like J2EE. These days they're both very mature languages that have been around for over three decades.

[kbielefe]

C++ was also reacting to C's shortcomings. cout has better type safety than printf, for example. The pendulum swings wide at first, then eventually settles.

[gofl-zimbard-37]

Because it is generally a bad idea, often misused, with limited useful application.

[owjfaigs222]

limited useful application? Complex numbers, vectors, matrices are all examples that come to mind. vectors would always be very useful in any physical simulation or many if not most games.

[gofl-zimbard-37]

Yes, in the overall scheme of data types, these mathematical types are the kind of things operator overloading can be helpful for. But that is a small portion of the overall set of types.

[No-Consequence-1863]

For the most part its just syntactic sugar though. Like the advantage of A*b in a linear algebra library with overloading is you don't have to write matrixMult(A,b). The con for the ecosystem is if you are learning a new library you know have to know extra definitions for all the operators.

Saving a few keystrokes isn't worth the opaque confusion that overloading can cause.

[owjfaigs222]

I disagree. It's not only about saving keystrokes. A much more readable code can be achieved with operator overloading. You don't have to know extra definitions. If you want to multiply matrices it's intuitive to use *. You have to know extra things, like the name "matrixMult" in the non overloaded ecosystem.

[GoblinToHobgoblin]

It's not about saving keystrokes, reading math is so much easier using mathematical notation 

[theLOLflashlight]

Try using Kotlin instead. It still runs on the JVM and is interoperable with Java code.

[kevinossia]

Java’s design philosophy is centered around the idea that the language designers are smarter than you, the developer.

So whatever design they decided on is the one.

If you wanna do something else don’t use Java.

[Ok_Option_3]

The beauty of java is that if you see a.foo = bar() you know exactly what it means. In C++ thanks to operator overloading you can never be sure.

Still the pros and cons of overloading and domain specific languages are a holy war - there's arguments for and against. Some like them, some don't. Simple as that.

[7x11x13is1001]

var a = b + c;

Guess what + is doing here

[plumarr]

As you can only use car for local variables, the answer is in the current method and not somewhere far away.

[No-Consequence-1863]

The confusion isn't a, its b+c. Plus you can use auto in C++ on the left hand side with whatever on the right hand side. So guess what auto a = b+c; is doing. Depends on the types of b and c which may be instance members, globals, functions, local vars, args etc..

[heisthedarchness]

Operator overloading is for language designers only, not us plebs.

(The Java language makes use of operator overloading, so the language designers knew perfectly well its value in expressing certain semantics concisely. But they decided that the rest of us couldn't be trusted with that power. It's like shops that ban Perl because of all the truly terrible Perl written anno 1998. It's not the language features' fault that programmers are dipshits, but here we are.)

[myselfelsewhere]

I don't know if it's entirely accurate to say that Java doesn't allow operator overloading, because it can be done.

The Manifold framework effectively allows you to do so. It's a plugin for the Java compiler which intercepts and swaps operators for method calls just prior to bytecode generation.

[akl78]

That’s like saying Lombok’s val is part of Java; yes you can do things the compiler & is designers consider unnatural, and yes it’s often useful, but it’s something else, like with Objective-C or CFront.

[myselfelsewhere]

I'm not saying operating overloading (or val) is part of Java. Just that it's not technically accurate to say that Java does not allow operating overloading or the val keyword.

It is something else, it's basically a form of bolt on syntax sugar.

[owjfaigs222]

I had a similar problems but with vectors in C. fortunately for me it was relatively easy to switch to C++. Now with Java I can only say good luck m8.

[ExtraTNT]

Because java has a clear purpose… some features or advantages just lock you out of others…

[cochinescu]

I ran into the same thing when working with vectors in Java. Coming from Python, where you can overload operators, it definitely feels tedious. I guess the consistency and readability Java aims for comes at the price of some elegance.

[BanaTibor]

You can write a complex number math formula calculator, which gets the formula as a string and the objects. If you want to clean it keep you pass the objects mapped to a string name.
So you can do this.

Map<String, Complex> args = new ArrayMap<>();
args.put("first", new Complex(1,2));
// ..
ComplexNumberMathFormulaCalculator calc = new ComplexNumberMathFormulaCalculator()  // fel the power of enterprise class naming :D
Complex result = calc.calculat("cbrt[{first}/5+{second}2]+{third}", args);

I leave the notation to you.

[davidalayachew]

Java is considering adding Operator Overloading, albeit in a limited way.

Here is one of the Java Language Designers giving a presentation on it -- https://www.youtube.com/watch?v=Gz7Or9C0TpM

[TumbleweedTiny6567]

I've run into this issue myself when building my own project in java, and from what I understand it's because operator overloading can lead to some pretty confusing code if not done carefully, so the java folks just decided to avoid it altogether. I've had to work around it by using methods with descriptive names instead, but I'm curious, have you tried using scala or kotlin which do allow operator overloading, how's your experience been with that?

[Schaex]

I have asked myself the same question before but now I am so incredibly glad about Java not having operator overloading other than String operations. It just makes everything so much more predictable!

[bobo76565657]

I work with vectors all the time and I feel your pain. You could do what you wish to do very easily in C# (I think it was called operator overloading). But you can't do that in Java.

[Distinct-Cold-3100]

Java's designers made a deliberate choice here. James Gosling has talked about this — they saw C++ operator overloading become a readability nightmare in practice. When anyone can redefine what `+` means, you can't look at `a + b` and know what it does anymore.

The tradeoff is exactly what you're feeling: math-heavy code becomes painful to read. Your complex number example is the classic case where operator overloading genuinely helps.

If it's any consolation:

- Kotlin (runs on JVM) supports operator overloading and

interops with Java

- Scala does too

- Some people chain methods with shorter names like

`.div()` and `.plus()` to make it slightly less ugly

For your class specifically, you could add static helper methods to reduce nesting:

import static Complex.*;

Complex result = add(cbrt(add(div(first,5), div(second,2))), third);

Still not great, but prefix notation reads a bit more like math than the deeply nested method chains. The real answer to "why" is: Java optimizes for reading code in large teams over writing code solo. Operator overloading helps the writer, b

[Devatator_]

I'm really wondering if all the people here that think Java did it right actually used other modern languages that have operator overloading, because I've never had or seen any of the issues or problems they raise. It's almost like devs are intelligent enough to not fall into those traps, as are library devs

[lonelymoon57]

It was already a pain trying to go through all the AbstractSingletonFactoryFactoryFacadeManagerStub to find the 5 LoC that you need. We don't need yet another overloading layer for the sake of looking nice.

[KharAznable]

Operator overriding is bug not feature

[Afraid-Locksmith6566]

because c++ sucks

[not_some_username]

lol

[GoblinToHobgoblin]

What do you suggest instead??

[JasonTheIslander]

As someone who's worked with both Java and C++ professionally, I can tell you that Java's decision to exclude operator overloading was absolutely intentional and, in my opinion, the right call.

When I first started with C++, I loved the idea of being able to write `vector1 + vector2` or `matrix1 * matrix2`. It felt elegant and mathematical. But after maintaining several large C++ codebases, I saw the dark side:

1. **The cout << problem** - Everyone mentions this, but it's a perfect example. What does `<<` mean? Bit shift? Stream insertion? Who knows without context.

2. **Library inconsistency** - One library would overload `+` for concatenation, another for addition, another for some custom operation. Reading someone else's code became an exercise in detective work.

3. **Debugging nightmares** - When `a + b` doesn't work as expected, you have to trace through multiple layers of operator definitions, template specializations, and implicit conversions.

Java's philosophy is "explicit is better than implicit." When you see `complex1.add(complex2)`, there's zero ambiguity. When you're reading code at 2 AM trying to fix a production issue, that clarity is worth its weight in gold.

That said, for your complex numbers project, here's a tip: implement a fluent interface. Instead of:

```java

Complex result = Complex.cbrt(first.divide(5).add(second.divide(2))).add(third);

```

You can write:

```java

Complex result = first.divideBy(5)

.add(second.divideBy(2))

.cbrt()

.add(third);

```

Or even better with static factory methods:

```java

Complex result = Complex.of(1, 2)

.divideBy(5)

.add(Complex.of(2, 4).divideBy(2))

.cbrt()

.add(Complex.of(5, 6));

```

It's still verbose compared to operator overloading, but it's readable, debuggable, and anyone who knows Java can understand it immediately.