Conclusion : IMO java doesn’t support operator overloading NOT BECAUSE the feature itself is bad, but because the Java team LACKS ability to do it.

I’ve developed useful production software in C++, Java, C#, Ruby and Scala. I have developed simulation-like applications in C++ where the operator overloading feature allowed me to clearly express what I had in mind. I have developed tons of enterprise applications in C# where I didn’t even once need that feature. I see no point in discussing “i have never needed this feature, thus it is not necessary” or “the guys at tomcat didn’t need it”, because it all boils down to personal experience based on the projects you have been working on.

Regarding java in particular, the language was originally designed to work in embedded environments, be it cellphones or applets. It evolved successfully to cover enterprise software needs, and it is there where it’s main market share resides. So it comes to no surprise to me that after this so many years the language doesn’t include operator overloading features. Unfortunately the language is not a “general purpose” one, in it’s broader sense, and as such it does not include “general purpose” language utitlities. I don’t think this in inherently wrong, language design is about trade-offs: we don’t include operator overloading in the specification, leaving behind scientific and engineering developers (which we don’t care much about) but keeping the specification simple for enterprise developers (which we do care about).

What I DO think is a rather questionable practice is the resilence of the java community to even CONSIDER changes. I don’t know of any kind of improvement on the java language on the past 4 years. I think we would all agree that the java language is not a perfect one, so why are we not doing anything to change it?

In the end, the result of this stagnation is that many BRILLANT developers I know of moved on to another platform. And I cannot blame them. We are talking about a language that hasn’t introduced any kind of change in the previous 4 years. A language that has missed 4 years of improvement opportunities. A language that is not moving in any direction.

A language that seems to be dead.

However, the number of times I’ve found, in practice, that it comes up that one might happen to actually want to use one of those relatively small number of examples is actually staggeringly large. Computer games, graphics programs, or almost any type of program that involves a simulation of some kind may need to utilize some form of group, ring, or field that is simply not managed or well represented by any class that is built into the java API, and attempting to restrict operator overloading only to certain select classes would simply not be adequate or efficient.

Ultimately, for such programs, writing something like position = position + velocity * time + acceleration * time * time / 2 is going to be *FAR* more legible than position = position.add(velocity.multiply(time)).add(acceleration.times(time*time).divide(2)), not to mention the fact that the latter doesn’t even read grammatically correctly. In practice, one would have to probably comment such code with the more legible form simply so that it would be better understood, but this fact just serves to exemplify the point that the usage of operators in the first place can actually dramatically *improve* the legibility of the programmer’s code in cases where their meaning is well understood, and it is simply undeniable that such things do not commonly arise in certain types of programs (of which there are no small number).

In the past, Sun’s response to developers who have expressed interest in operator overloading for this reason do not typically attempt to dispute the validity of this point, but instead, they simply dismiss the entire notion of operator overloading with the sweeping statement that Java is not designed to be used for such programs. This response is problematic because the reason that is initially cited for not having operator overloading in Java is not that Java is not designed to be used for projects where operator overloading might make logical sense, but rather, the reason given is always one of source code legibility. This logical shifting of the goalposts is not indicative of a well reasoned design. At worst, such a response can all too easily be interpreted as telling such developers “go back to C++, we don’t want your kind messing up our language with your newthink”.

Finally, again, I do not dispute that the number of cases for which operator overloading is useful is relatively small compared to the number of cases where it can be easily abused, but I *DO* maintain that the actual number of distinct programs that a person might write where one of those cases ends up applying is actually very, very, very large in my experience, and, with some care taken in how it is actually done, could possibly be added into Java in such a way as to minimize its abuse, or at the very least restrict abuse to situations where it is unlikely to be problematic for professional software development where often quite strict coding conventions have to be adhered to in the source code.

What you need is language-defined support for decimal types and the use of operator symbols such as + on those types, not a general purpose operator overloading mechanism for all user-defined types. The problem with operator overloading is that there really aren’t many good use cases for this. Decimals are one. Complex numbers are another. There are others, but they are increasingly obscure.

Whether a language chooses to support a feature or not does not inherently make it dirty or clean. It’s a feature that you may either choose to use or not. Personally I think this whole topic would go away if there was a proper decimal native type in Java. That’s my need at the moment and BigDecimal (being the abomination that it is) makes using java for a project I’m on untenable. I would love to use Java but until there is a native decimal type so I can code a = N * 10.5 + 3.25 rather than a = n.multiply(new BigDecimal(10.5) + new BigDecimal(3.25)) I will have to use C#. Any other argument is pointless because it doesn’t change that basic fact.

Steve

Now how would I recommend that operator overloading be added to the language in such a way that it wouldn’t be abused? Unfortunately, as another poster remarked, it’s just as easy for a lazy programmer to name a function plugh() as it is for somebody to abuse an otherwise useful feature like operator overloading to create code that is not easily understood. I suspect that adding a notion of const-correctness to java and requiring that overloaded operators observe such correctness on their parameters would help matters somewhat, but of course I’m sure that even that could probably be hacked around.

However, as has been admitted by many people here, there are many use cases where certain overloads absolutely make sense, and where the lack of these overloads makes using these objects in Java quite obnoxious: BigDecimal, BigInteger, vectors, complex numbers, matrices, and quaternions are the ones that people are usually thinking of when they beg for operator overloading.

There’s an obvious solution here: if giving us operator overloading hurts too much (I’m not entirely convinced, but…), we could at least be provided with Magic Objects (like String) for each of these important and commonly used types, and have the compiler specially add that syntax sugar. That adds some new syntax, so it will probably never happen, but it seems like an extremely reasonable solution to me…

My proposal for (dual) operator overloading is such:
1.The result is returned.
2.No object instance is mutated.

1 is obvious. 2 could be enforced by the compiler – at least I’m sure it could. Just make assignments to this.* invalid. This rids you of the problem (which is, in fact, there in C++ as well). [Granted, there may be ways to do it by side-effects, but hey!, in complex languages like Java you can always work-around something. And if it's by reflection...]
Of course, never anybody will be able to keep dumbheads from inventing strange uses for specific operators. But I’ve seen similar things with named methods.

And there’s oh so many uses for operator overloading. After Java5, it’s the one thing I always said is missing from Java to make it a great programming language. Remember generics? Done mainly with preprocessor in C – baaad. Great implementation in Java. Why not try to do it the same way in Java, getting rid of the problems. Granted, there may be more to it than my two cents above, but that already rids you of one ambiguity…