Why Java does not support Operator overloading (Guest post)

This article was originally posted by Javin Paul at Javarevisited.

Unlike C++ java doesn’t provide freedom to programmer to overload the standard arithmetic operators e.g. +, -, * and /, Java has left lot of feature supported in C++ e.g. Java doesn’t support multiple inheritance, no pointers in Java and no pass by reference in java. Rarely this question asked in interview to check how programmer thinks about certain features which java doesn’t have. Though I don’t know the real reason behind it I think following observation make sense on why Operator overloading is not supported in Java.

1) Simplicity and Cleanliness

Simple and clear design is one of the goals of java designer they just don’t want to replicate the language but wanted to have a clear, truly object oriented language. Adding Operator overloading will definitely make design more complex than without it and it also slows the JVM because it needs to do extra work to identify the actual meaning of operators and reduce the opportunity to optimize the language by guarantee behavior of operators in Java.

2) Avoid programming errors

Java doesn’t allow user defined operator overloading because if you allow programmer to do operator overloading they will come up with multiple meanings for same operator which will make the learning curve of any developer hard and things more confusing and messing. Its been observed that there is increase in programming errors when language supports operator overloading which in turn increase the development and delivery time and since Java and JVM has taken most of developers responsibility in memory management by proving garbage collector it doesn’t really make sense to left this feature to pollute the code and a loop hole for programming errors.

3) JVM complexity

Form JVM perspective supporting operator overloading is more difficult and if the same thing can be achieved by using method overloading in more intuitive and clean way it does make sense to not support operator overloading in java. a complex JVM will result in slower JVM than a relatively simpler JVM and reduce the opportunity of optimization by taking out guaranteed behavior of operators in java.

4) Easy development of tools

This you can think of an additional benefit of not supporting operator overloading in Java.omission of operator overloading has kept the language easier to handle and process which in turn makes to developed the tools that process the language e.g. IDE or re-factoring tool. Re-factoring tools are far better than C++.

In conclusion many things which can be achieved via operator overloading can be achieved using method overloading using more intuitive and easy way and that might be the reason java designer thought that supporting operator overloading will not be a big benefit for language, but in fact only java designer can answer real motivation of why Java doesn’t support operator overloading, like some other questions as Why Java doesn’t support multiple inheritance or Why String is immutable in Java.

* The views expressed in this article are those of the author and do not necessarily represent the views of, and should not be attributed to, Jelastic or its technology and distribution partners.

7 Responses to “Why Java does not support Operator overloading (Guest post)”

  1. Why Java does not support Operator overloading (Guest post) | Jelastic — Die nächste Generation Java-Hosting-Plattform

    [...] Marina Sprava hat einen neuen interessanten Artikel in unserem englischen Blog geschrieben, den wir Euch nicht vorenthalten wollen. Why Java does not support Operator overloading (Guest post) [...]

    Reply
  2. zproxy

    C# operators compile down to static methods. When JSC crosscompiles .NET bytecode to Java source code, all operators appear as static methods, usually with prefix “op_”.

    Reply
  3. Andy Till

    The only reason operator overloading is not in Java is because it is a political minefield. If Oracle adds the feature then people will moan, so it is best for them if it is not mentioned (and only a minority moan).

    Pretty much every other language supports operator overloading, usually it is just an alias of a plus method on an object. A lot of those languages are on the JVM already.

    Reply
    • Dan Howard

      Nope. Java does not have operator overloading because it’s a really bad idea. This feature was left out of Java because it was a single point of failure in SmallTalk. We never learn apparently since Microsoft re-introduced this bad idea in C# and now code monkeys like you think it’s a good idea.

      Reply
  4. Anton Arhipov

    “JVM complexity” does not have anything to do with operator overloading. Other languages do it by convention (hint: Kotlin) and it doesn’t affect JVM or whatsoever. As a cosequence, development of tools isn’t very much affected by this language feature as well.

    Reply
  5. James

    I agree with @zproxy

    Reply
  6. Jim Clack

    Marina, Dan, et al. FYI – Java does not support operator overloading for the same reason that COBOL doesn’t. Java is not a general purpose PL but only suited to business apps, typically on a server. You will not find many engineering, mathematical, or graphical rendering applications written in Java – in fact only a small fraction of the number that have been written in C#/VB.NET. When Java was first introduced there was was a lot of outcry about it lacking this feature; but in later years all of those people moved to more well-suited languages and so you see little complaint nowadays.

    Engineers/Mathematicians/Systems developers refused to move to C from Fortran for a long time until C++ introduced operator overloading. When one is dealing with large vectors, quaternions, and very large matrices, the code becomes almost illegible if you cannot use natural syntax. Of course this does not mean that “just any operator should be overloadable in any possible manner,” and a good solution would make improvements over the C++ approach. We need an ability to use mathematical operators and subscripts (brackets) on various sorts of container objects, that’s all.

    Anyone that says that it’s a bad idea or that it’s just syntactic sugar reminds me of the infamous (as quoted by Ted Nelson) programmer that said, “If it can’t be done in COBOL, I just tell people that it can’t be done by computer.”

    BTW, I am not a C++ or .NET zealot – I develop primarily in Java. But I find it frustrating to use for mathematical problems. I claim that Java is the COBOL of the new millennium.

    Reply

Leave a Reply