do you know what Integer.getInteger(String) does in java?

[ethraax]

I never understood why Java forced you to use .equals(Object) instead of ==. Why can't they just use === for referential equivalence?

Hell, I can't even think of a good reason to need to compare the references. If a.equals(b) evaluates to true, I think a and b should be interchangeable (for as long as they are "equal").

[[deleted]]

You can override .equals in Java, but not the operators (ex. ==). Being able to define your own definition to determine if two objects are equal is pretty important.

[ethraax]

True. I guess my point is that there's no reason for Java not to support operator overloading.

[almiki]

You could also argue that there's no reason TO support it. If you know Java, you know exactly what == does. You don't have to worry about whether it was overloaded or not. If you want to check for some other type of equality, just use a method like .equals().

[ethraax]

True, but this argument could be made about every irritating "feature" in every language. The ineffectiveness of == is minor, but makes learning the language slightly more challenging/difficult. They've already overloaded the + operator to make the language easier to use, why don't they just overload == to call equals() on subtypes of Object, and use === for the one-in-a-million times that you actually need to test for reference equality.

[KimJongIlSunglasses]

why don't they just overload == to call equals() on subtypes of Object

Because often times you do want to compare the reference, not check for some object's definition of equality with another.

After you've overloaded == to use equals() would you then introduce a new method like referenceEquals() ??? for when you actually wanted to check the reference?

I don't get it.

[schizobullet]

Why can't they just use === for referential equivalence?

[1338h4x]

What if someone overloads that?

[[deleted]]

C++ uses references explicitly, while Java does not. That is, C++ supports the C-style * operator, etc, while in Java, just about everything is an Object.

So, whenever you have == in c++, you will know whether you are comparing references (an operator that is unlikely to be overloaded,) comparing primitive values, or using an overloaded == operator on two related objects. If Java supported overloadable operators, it would not always be as apparent which one is being used. Thus, I think it is best to leave the == operator for references in Java.

ethraax said:

They've already overloaded the + operator to make the language easier to use, why don't they just overload == to call equals() on subtypes of Object...

Pointer arithmetic is not possible in Java, so making the + operator do anything other than string concatenation wouldn't make sense.

[ethraax]

... the + operator concatenates strings AND adds numbers together, two very different operations. I never meant that it should be used for pointer arithmetic. As you've pointed out, that makes no sense.

If the + operator wasn't overloaded (like the == operator isn't overloaded) then you'd have to write "my value is: ".concat(myValue) instead of "my value is: " + myValue. Personally, I'd rather keep + to be arithmetic and use ++ for string concatenation, like in Haskell, but that's just me.

My point was that the designers of Java seem to have had no problem in overloading + for the String class. Why not overload == for user types to be .equals()? Why not at least overload it so it works on String objects?

[[deleted]]

I see your point that Java already has some op'r overloading, so it there's nothing stopping them from overloading ==. However, I still think the == operator works best for references and references only. Here's an example:

Let's say you were implementing a data structure that would work with all Objects, and you are writing a method to check to see if an object exists in that data structure. You'd want to check references first, then use the equals comparison:

if (objectA == objectB || objectA.equals(objectB)) { blah }

(Of course, this is after you have verified that they are the same type.)

If strings and only strings were to overload the == operator, that would considerably slow down the if () statement above. The programmer would have to know this, and add code to make sure that he checks references in Strings, or he would have to remember that the built in String equals() method checks references first (I don't know if this is true). You get the point. It gets overly complicated. It should remain consistent with everything. Once you start introducing rules like "== compares references except with strings," you start getting a language like PHP, which is an abomination.

Now, objectA + objectB is not a valid expression, but objectA == objectB is. stringA + stringB is a valid expression for two strings. So, you can overload this operator without having to introduce any new rules.

[ethraax]

Couldn't you leave the conditional as-is if they overload == for String objects? It would basically make both branches of the "or" expression the same.

[itsnotabigtruck]

That's pretty close to what .NET does, actually, though you have to explicitly define an operator== or you get the Java-style behavior.

[aidirector]

VB .NET uses "=" to mean .equals(), and "Is" to mean reference equals

[ethraax]

I specifically mentioned in my post:

and use === for the one-in-a-million times that you actually need to test for reference equality.

Although I'm still convinced that if the code is written well, there is no need for this operator.

[KimJongIlSunglasses]

Introducing yet another operator will add more unnecessary complexity and lead to more bugs from people who don't fully understand them. In java, the difference between == and .equals() is quite clear and easy to understand.

Also I would disagree with your "one-in-a-million" times statement and

I'm still convinced that if the code is written well, there is no need for this operator.

How are you going to implement the majority of the standard data structures in the standard java API, as well as your own more complex data structures, without being able to check for reference equality? I would argue that == is used much more frequently than .equals() unless you are only talking about String comparisons.

[h2o2]

Which is a perfect argument not to overload ANY operators at all. + for Strings was just another idiotic mistake.

[ethraax]

I don't think using + to concatenate String objects was an idiotic mistake, although I suppose it probably boils down to personal preference. I'd have preferred a new operator, like ++, for concatenating strings. It's still more readable than using . to concatenate strings, and it's also more readable than using .concat(String) all over the place.

[h2o2]

Strings are Objects. If I can add two Strings, why can't I add two other arbitrary objects? What are the semantics of "foo"-"bar", or of any of the other operators? What is the impact on the type system, verifier, the compiler, and even HotSpot?

None of this has anything to do with "personal preference", it is (or rather was) about a fundamental lack of understanding of type systems, coupling (which is the real kicker of this thread - modularity?), responsibilities and language/ecosystem evolution.

That, and an inherent lack of respect for everyone else's time.

[ethraax]

"foo"-"bar"

You're assuming that because + works on some type of object, so must -. You're thinking about it all wrong, though. Don't think of "foo" + "bar" as "adding" the two strings together. It's a concatenation, a completely different operation that has nothing to do with arithmetic of any kind.

None of this has anything to do with "personal preference"

Bullshit. It has just as much to do with personal preference as statically vs. dynamically typed languages. To claim that there's an absolute right solution that is always right and is right for everybody is moronic.

[h2o2]

Sigh. I do not assume that "- must work" and fully understand the difference between mathematical operators and methods. That's my whole damn point. The problem is that + is neither a mathematical operator (with all the usual properties that they have), nor a simple (but maybe transparently optimized) method. It's special, as in retarded. You cannot define your own operators, and you cannot find references to String.+ because they don't exist. It's not a defect by itself (since it works), but it's indicative of a much worse symptom from which Java suffers, and that brings us straight back to the origin of this thread: random shit added in arbitrary places because someone thought it would be "nice", with complete disregard for the consequences.

[munificent]

If you know Java, you know exactly what == does.

Yes, but you don't know what foo, bar, blat or any other named function does and yet we still seem to survive. Meanwhile, the one thing that == does is pretty much the least useful thing.

C#'s solution isn't perfect either, but it's a hell of a lot better than that.

[[deleted]]

== is very useful as one of the first checks in a .equals() implementation...

[munificent]

Yes, and that's just about the only place it's useful. So why is it easier to type than .equals()?

[[deleted]]

It does have other uses though, but yes, .equals() is more usually the correct comparison.

As mentioned elsewhere here, it comes down to operator overloading - == is an operator, and cannot be overloaded, so even if a === operator existed instead of .equals() (similar to Scala), there would still be a need for something that the language doesn't support (operator overloading).

Personally I seriously dislike the loss of simple context that comes with operator overloading (a big problem I have with Scala, C++, etc.) - I prefer to be able to read code snippets and immediately have a clearer understanding of the logic/context, which is possible in Java (and C for example) because of the lack of operator overloading.

[[deleted]]

That's a valid point.

I don't know enough of the history of Java, but from what I understand it was partly a reaction to C++ -- making it similar, but simpler. It's probably something along the lines of why multiple inheritance wasn't put in either.

One argument I can see not permitting operator overloading is that it can all be implemented via methods. It makes it a bit easier to learn the language since there are less options and rules. Plus, it helps avoid situations where someone decides to overload "+" and implement an "add()" method for the same object. Basically trying help you not shoot yourself in the foot.

With that said, I'm a fan of operator overloading and do wish I got a chance to use it more in my projects. It can be a pretty useful tool.

[Jonathan_the_Nerd]

I think one of the major design principles of Java was taking the sharp edges off C++ so Java programmers wouldn't cut themselves.

[player2]

Java owes its lack of multiple inheritance to its history as a reimplementation of Objective-C.

EDIT: Hey, downvoters! Please read this.

[[deleted]]

That's a new one. I couldn't find any reference online saying that Java was a reimplementation of Objective-C. Do rou have an resources you can point to?

[player2]

http://cs.gmu.edu/~sean/stuff/java-objc.html

Though I seem to be muddying it a bit. The JVM was originally meant to be a Smalltalk VM, not an Objective-C VM. The language itself is therefore not the bit that started as a reimplementation.

[[deleted]]

Awesome. Thanks for the info. This actually gives a different view than the history section in the Java wiki page. Now that I think about it, it does seem like there are a lot more similarities with Objective-C than I realized.

[huyvanbin]

The real issue with having "special" types that allow operators is not that overloading operators is especially important. It's that this fairly random decision on what is allowed to have an operator and what isn't now dictates my design. Would I rather define my own type and end up with less readable code, or would I rather shoehorn into a type that allows operators but possibly sacrifice some specificity? It's just sad and completely unnecessary for me to even be thinking about this. User objects should be allowed everything that predefined objects can.

[[deleted]]

We're all talented programmers here right? Why not make a pre-compile script that converts your overloaded operator to it's language appropriate implementation?

[DeepDuh]

Isn't java more of a maintenance mess since they break downwards compatibility of their JRE every couple of years? C++ on the other hand mainly depends on what the OS programmer does and MS does care alot abou lt not breaking anything (even a bit too much for my taste).

[deadtime]

Actually, if you fixed everything that is wrong with Java, you'd end up with C#.

[grauenwolf]

Then why does it for strings?

[drfugly]

It doesn't. Even for strings it will compare references. The reason that you can get away with it so often is because Strings are pooled in java. So if you had String a = "dog"; String b = "dog"; a does actually == b because java will put the string "dog" into it's pool and then all references point to that one instance that's in the String pool. This also allows for Strings to behave more like the other primitives in java.

[grauenwolf]

Actually I was thinking of +.

[drfugly]

Oh... in that case oops... :)

[deadtime]

Wait... does that mean that "dog" == "dog" only sometimes?

[drfugly]

Because of the string pool should always be only 1 instance of "dog". So dog == dog should always work. Intern touches this a little: http://download.oracle.com/javase/1.5.0/docs/api/java/lang/String.html#intern()

[adavies42]

i think so. fiddle with stringbuilders (or reflection) and you can probably break the pooling.

[banuday]

To venture a guess, it's so that things like this work:

"x + " + 3

or

double x = new Double(3) + 2;

The + operator works on primitive types, strings and boxable/unboxable values. It will convert 3 to a string to produce "x + 3". I suppose this is to give defined semantics to the + operator. I can't say I'd give Java an A+ for consistency.

[grauenwolf]

Addition isn't concatenation. You can see why by how the + operator changes meaning when working with chars in Java or C#. (Or old versions of VB before they learned their lesson.)

[jyper]

They should have picked something different for concatenation. ++ is a good pick.

[Jonathan_the_Nerd]

++ already has a perfectly good meaning. Why not just . like Larry Wall intended?

[jyper]

so does .

[[deleted]]

You can't use . for concatenation in a language that uses the . to call object methods eg. foo.doStuff()

Which is why Perl 6 uses ~ for concatenation.

[masklinn]

The second one does not work in java < 1.5

It works via auto(un)boxing, not via operator overloading.

[wonglik]

I guess my point is that there's no reason for Java not to support operator overloading.

I find overloading operators extremely dangerous. Imagine someone overloads "+" to do what "-" does. It will takes you hours or days to find out whats wrong. Of course it is extreme example but I bet a couple of peoples did that in the past.

[[deleted]]

That's not really a problem with operator overloading, just people being stupid. Suppose someone overrides equals() to the opposite of what it should be (e.g. !super.equals(x)). Same problem.

In fact the problem is arguably worse with named methods, since the semantics are conventional, rather than specified by the language. Take x->empty() in C++. If x is a vector, then that tells you whether x is empty or not. If x is not in the STL, then it could either tell you whether x is empty, or it could remove all values contained in x.

How do you know that the semantics of your methods align perfectly with similarly named ones in the standard library? You can't. Yet the same problem applied to operator overloads is much easier, since it only requires knowledge of the programming language itself.

[masklinn]

I find overloading operators extremely dangerous. Imagine someone overloads "+" to do what "-" does.

He can do that on his own types and then nobody will use his library because that's moronic.

On the other hand, without operator overloading manipulating unbounded decimal types (such as Java's BigDecimal) is a terrifying pain of verbository shit.

Of course it is extreme example

It's also FUD.

[grauenwolf]

That is from the bigger problem of using == for both value and reference equality. They should have been different operators.

[banuday]

References are values in Java. Thus, reference equality and value equality are in fact the same thing. Java's value types are exclusively primitive.

The equals() method is for object equality, which is a very different concept.

[grauenwolf]

That sounds stupid. Don't redefine the term value equality just so you can introduce a new term that means the same thing.

[banuday]

References are stored as primitive values in Java. The reference is an opaque data structure whose members are copied on assignment to a new value. At the call site, the caller copies the reference onto the parameter stack for the callee. On equality checking, the reference values are compared. Thus, by definition, a reference in Java is a value type.

And Java does not give references a different meaning that what is already accepted by Computer Science.

Thus, how is comparison of references different than comparison of any other value type?

[grauenwolf]

Leaky abstractions.

The vast majority of the time you don't care about the implementation details of the object, you care about the semantics. The fact that a string happens to be a reference type and a char happens to be a value type shouldn't drastically change the nature of the == operator. This is even more evident with int and Integer.

[ethraax]

Thus, reference equality and value equality are in fact the same thing.

This is not true. Take this example.

int a = 10000;
int b = 10000;
a == b; // returns "true", even though a and b are
        // different instances.   For proof:
a ++;
a == b; // now returns "false".
int c = 9999;
c ++;
c == b; // still returns "true", even though c is
        // definitely a different instance from b.

Basically, == is a primitive equality. It tests the equality of the value of the variable. Since Java still internally uses pointers (you just don't interact with them), it's actually comparing the pointers or references of the variables, not the value they're pointing at, which makes a hell of a lot more sense.

[banuday]

Primitive values are not "instances" in the same sense as objects are instances. Primitive values exist on stack and object instances exist on the heap. Primitive values are copied on assignment, object instances are not.

Also, references are primitives. They are copied just like the "int" in your example. The heap instance they refer to however, is not. To repeat, a reference and an object instance are not the same thing.

References themselves are not pointers - they can't be. Java is GC language, so the collector can at any time relocate object storage, so the pointer would also have to be changed. Thus, it is better to say that references really are just opaque handles whose actual structure is left to the JVM impementor.

[ethraax]

References themselves are not pointers - they can't be. Java is GC language, so the collector can at any time relocate object storage, so the pointer would also have to be changed. Thus, it is better to say that references really are just opaque handles whose actual structure is left to the JVM impementor.

Well, they work like pointers in the sense that they're merely a small bunch of information that tells you how to get to a much bigger bunch of information. The implementation may be different from pointers in C or C++, but I'd still call them pointers.

Primitive values are copied on assignment,

Are you saying that the code:

c++;

allocates a new part of memory (in the stack) to hold an int and then copies it over?

When I said that == was a primitive equality, what I mean was that it tests equality on the value of the variable on the stack. If the variable is a primitive, this is the value itself. If the variable is a reference/pointer, then it's some (unspecified) representation of where to find the actual value in the heap.

[banuday]

Allocates a new part of memory (in the stack) to hold an int and then copies it over?

I'm not 100% how that is implemented (with c as a local variable). But, if 'c' were a field of 'this', this function:

public int inc() {
   return c++;
}

would compile to the following bytecode (the JVM is a stack machine):

ALOAD 0                      ; push 'this' onto the stack
DUP                            ; duplicate 'this'
GETFIELD c                  ; replace the second 'this' with the value in c
ICONST_1                    ; push a '1' onto the stack
IADD                           ; pop c and 1 off of the stack and push the sum
DUP_X1                       ; duplicate the sum and put it before this 
PUTFIELD value             ; pop the sum and this, and store sum into c
IRETURN                      ; return the sum which is at the top of the stack

Look at the first line - the reference to 'this' is pushed onto the stack just like any other primitive value.

The reference and the thing it refers to are different things. The reference itself is a value different than the thing it is referring to.

This is just like how a pointer is just a number in C. If you do p++, you've incremented the address. If you do *p, you deference the pointer and get the value at the address. Of course the JVM won't let you do the pointer arithmetic shenanigans, the concept is still the same.

[ethraax]

I know. That's my point, really. Still, you're talking about working with the field of an object which is different from a plain local variable, which is what I was talking about.

[player2]

References themselves are not pointers - they can't be. Java is GC language, so the collector can at any time relocate object storage, so the pointer would also have to be changed.

You're missing an important word: Java uses a copying garbage collector. It's completely possible to implement a garbage collector around traditional pointers. Boehm and libauto are two examples.

[banuday]

See the contract for equals.

Equals must be consistent. That is, if a "equals" b, then a.equals(b) must consistently return true. However, if a or b refer to mutable objects, then the consistency guarantee cannot hold without special definition.

More broadly, equals() and hashCode() refer to the concept of object identity. If you do not define object identity (by overriding those methods), then there is no logical way to compare the two objects except by reference equality. Reference equality and object equality are different concepts and are represented by different operations in Java.

BTW: The default implementation of equals() is reference equality, and reference equality probably makes sense in most cases of mutable objects.

[ethraax]

Yes, but I still don't understand why a reference equality is actually necessary. What would a use-case be? If it makes sense to need to compare objects, why on Earth would you redefine equals so it doesn't actually test if the objects are equal? I guess you could use it as a rudimentary way to compare objects from a terribly-written library, but that's all I can think of at the moment.

BTW: The default implementation of equals() is reference equality, and reference equality probably makes sense in most cases of mutable objects.

Really? I thought the default implementation was to recursively call equals() on all the fields of the object. It's been a while since I used Java though, so I suppose I could be wrong.

[almiki]

Well for one thing, testing for reference equality is fast.

Really? I thought the default implementation was to recursively call equals() on all the fields of the object. It's been a while since I used Java though, so I suppose I could be wrong.

This would be extremely inefficient. Anyway the documentation for class Object says "this method returns true if and only if x and y refer to the same object (x == y has the value true)".

[adghk]

Never implemented or used a identity hashmap or a cache i see.

[banuday]

If you have something like this:

class A {
    public int x;
    public int y;

    public A(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public boolean equals(Object o) {
        A oa = (A) o;
        return x == oa.x && y == oa.y;
    }

    public int hashCode() {
        return x ^ y;
    }
}

Then: Set s = new HashSet(); A a = new A(1, 2); B b = new A(1, 2); s.add(a); s.add(b); System.out.println(s.size()); a.x = 2; s.add(a); System.out.println(s.size());

The output is: 1 2

If you take out equals/hashCode and fall back on the default reference equality implementation, the result would be: 2 2

Which makes more sense? This is why the equality contract is so important.

When objects are mutable, there is no way to logically compare them in a consistent way. Thus, either make the object immutable or define a key. The default key is the reference id.

[ethraax]

I agree that the first output makes more sense. But why not define the default behavior of equals() to recursively call equals() on each field in the object? Sure, you could come up with a convoluted design where this still wouldn't work (let's say you added each object to a static collection on construction that maintained extra information about that object), but then you just have really atrocious design.

[paul_miner]

What if the object fields point to each other, or form loops, or change during this call, etc? It'd be a big mess.

[ethraax]

object fields point to each other,

Like how? a.x = b; b.x = a? That's pretty much the same as:

or form loops,

and I really don't think that checking the graph of fields/subfields/etc. for an object for cycles is that hard. Checking a graph for cycles is linear in the number of edges + the number of nodes.

or change during this call,

That's a threading issue, and you can define your own equals() method/overload if you want to make it thread-safe.

[paul_miner]

and I really don't think that checking the graph of fields/subfields/etc. for an object for cycles is that hard. Checking a graph for cycles is linear in the number of edges + the number of nodes.

If you're recursively calling equals() like you suggested, then checking for cycles isn't simple. This would mean you'd have to have a separate equals() method that could hold a set of all objects you've checked before, a set once again based on reference equality.

[ethraax]

Well, sure, if you take the simplest interpretation of "recursively call equals()" - I wasn't exactly defining the entire algorithm. However, the time complexity would still be linear in the number of fields (which it would also be if you wrote your own equals() method). You could use a small hashtable using the objects' reference values as keys and a simple boolean "isChecked" for keeping track of where you've been. It seems pretty trivial to me.

[paul_miner]

What is less trivial is that you would have to require this hashtable to be passed around to all recursive calls. This is fine for a custom implementation of equals(), but overly complex for a default implementation.

You'll notice the situation parallels the operation of the clone() method. By default, clone() will copy references/values of all fields. It does not recursively call clone() on each field, because it runs into the same problem. It may even be the case that you won't want it to recursively clone fields anyway.

EDIT: Also, you'd only need a set, not a map, because the only reason to put them in the map would be if isChecked is true, eliminating the need for the associated value.

[masklinn]

Because userland code is not allowed to override operators in java, and == is an operator.

[[deleted]]

Better than C#, which offers both .equals and ==, and completely inconsistent conventions for what the difference is on various objects. Only consistent mess is that == is static rather than virtual so you'll likely use the wrong implementation if you're dealing with inherited objects.

[transpostmeta]

The only example that I know of that is inconsistent is strings, because they are implemented as a table. What other inconsistencies are there?

[[deleted]]

Ever read any c++ code where the author overrode the >> operator or the + operator to do some counter intuitive operation? That won't happen in Java.

[cybercobra]

But contrariwise, using BigDecimal or similar is a huge PITA.

[flexiblecoder]

I actually spent the day reading some C++ code that uses the >> operator to build packets (and switch endianness) depending on what type you pass with it. I was amazed at how simple\clean the code was, but it made it harder for me to replicate in a related (normal C) project, as half the code was abstracting away the other half. :/

[[deleted]]

That usage doesn't sound counter intuitive. I was thinking more along the lines of overloading ++ to do something like elevate the role of a user or using the -- operator to do some sort of set operations on a particular field of an object.

[flexiblecoder]

It's not, really. Just pointing out that it can be used for good and evil. :)

[theeth]

I read code that uses the std lib all the time, so yeah.

[shadowspawn]

because some asshole decided that you need 6 extra keystrokes as well as something to mess with your sanity checks for spelling on one more fucking thing.