• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why Doesn't Java Have Operator Overloading?

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Java Tiger has many new features. I appreciate the convenience and more natural syntax operator overloading provides for objects in expressions.

Anyone have any hypotheses as to why Java does not offer operator overloading in its latest release?
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One of Java's core philosophical aspects is transparency: what you see is what you get. When you read Java code, you always know exactly what you're looking at, and it's (relatively) easy to jump from project to project.

In (say) C++, where you can redefine the behaviors of the basic operators, it's not longer possible to be sure you know what you're looking at when you read code. Macros have the same bad effect, which is why Java doesn't have a preprocessor.

Now, don't argue with me about how you like operator overloading -- that's fine, you're absolutely welcome to like it. But the folks who are the keepers of the Java faith don't, and for sensible reasons.
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
because the authors of the language specification are dead against operator overloading and multiple inheritance.

No other reason is needed...

And I happen to agree with them, having seen what a mess operator overloading and multiple inheritance almost invariably cause (in fact I've been a bit guilty of it myself, as has I think everyone who ever wrote C++).
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I recall a conversation on a C++ project I worked on:

person 1: "hey [person 2], you overloaded the arrow [member] operator?"

person 2: "this from the person who overloaded the bracket [array subscripting] operator?"

Ernest is correct. In fact, some people object to autoboxing in Java 5 on the basis that it loses some transparency.
 
Joe Cuppa
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"people object to autoboxing in Java 5 on the basis that it loses some transparency"

It was Java's inclusion of autoboxing that got me thinking that Java has operator overloading at least for the wrapper classes and operator=. I started to wonder why not more and for more classes.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
autoboxing is no operator overloading.
It may look like it


does print
1
2
3

but what really happens is that the last statement gets translated at compile time to
l.add(new Integer(((Integer)l.get(0)).intValue()+((Integer)l.get(1)).intValue())); (give or take some braces).
Similar casts and wrapping gets performed when adding and retrieving ints to and from the List.
 
Joe Cuppa
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know how it's implemented, but what you've just described to me sounds a lot like what happens in a preprocessor. Yes, I realize Java does not have a preprocessor, but a phrase such as "statement gets translated" sounds a whole lot like the function and functionality of a preprocessor.+
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes, generics resolution takes place in what could be described as a preprocessor.
It's of course actually an extra pass by the compiler itself but the effects are similar.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeroen Wenting:
yes, generics resolution takes place in what could be described as a preprocessor.
It's of course actually an extra pass by the compiler itself but the effects are similar.



And it's nothing new. It's, for example, also what's happening for the String concatenation operator "+" - it's translated into method calls on StringBuffer objects.
 
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An interesting topic !!

It's easy to understand the motivation for eliminating operator overloading for the reasons of preventing the abuses that were seen in C++. However, "operator extension", for true value types really is a nice expressive and transparent concept.

It's hard to make a good argument given a true value type like a Complex number class that

is somehow more transparent than


The real problem is the potential for inappropriate "operator subversion".

Preprocessor is just another name for "code generator". I guess if I wanted this syntax badly enough I could write my own preprocessor. but it's a lot of work and an extra build step.


The other issue of multiple inheritance has similar valid motivations. Unlike opertor overloading however, the attempt to keep multiple inheritance out of the Java software development world has been made largely irrelevant by the growth of the use of AOP to implement cross cutting behavior. AOP strategies have been around in the Java world for quite a while now to implement cross cutting behavior for remoting, security, and transactions. AOP techniques encompass all the Java power tools, reflection (dynamic proxies), code generation, custom class loaders, attribute metadata, and bytecode manipulation. AOP has the potential to make software more transparent and reusable by eliminating the tangle that occurs when mixing cross cutting aspects in with the domain logic.

As any factory or construction worker can tell you, power tools can be very dangerous and should be used with safety and good judgement. Just because they are dangerous doesn't mean we shouldn't use them. A healthy dose of common sense and a professional engineering approach to their use should rule the day so that they make software more transparent and reusable, not less.

[ February 08, 2005: Message edited by: Ken Krebs ]
[ February 08, 2005: Message edited by: Ken Krebs ]
reply
    Bookmark Topic Watch Topic
  • New Topic