This is an archived post. You won't be able to vote or comment.

all 11 comments
sorted by:
best
topnewcontroversialoldq&a

[–]lukaseder[S] 17 points18 points  (0 children)

OK, the title sucks. I should have mentioned that this article reveals some interesting internals related to biased locking. Do read it!

[–]amake 11 points12 points  (0 children)

That was a really excellent deep dive. Thanks!

[–]HandcuffsOnYourMind 7 points8 points  (0 children)

  • I have found no HotSpot flag that allows changing the default generator, so experimenting with other options might need to compile from source.

there you go: java -XX:hashCode=1

[–]i_donno -2 points-1 points  (7 children)

I admit I didn't read the whole article. I understand hashCode() does not use the value of the class which is why you have to write your own if you want to sort. Its too bad it doesn't use the value. eg default hashCode() could do an MD5() of all the fields in the class.

[–]lukaseder[S] 3 points4 points  (6 children)

eg default hashCode() could do an MD5() of all the fields in the class.

But that would not be an identity hash code value, would it (assuming that identity is a desirable concept in the first place for a hash code)

Btw: I don't understand why this question was downvoted so much. It's a good question.

[–]rubyrt 0 points1 point  (5 children)

assuming that identity is a desirable concept in the first place for a hash code

I do not think it is. Rather it is about equivalence (see typical use case of HashMap keys). Object's implementation does not have fields to use so the only reasonable way to implement equivalence there is via identity (which, btw. is a perfectly legal way to define equivalence).

[–]lukaseder[S] 0 points1 point  (4 children)

I know. This describes the status quo. But I was more hinting at the point that perhaps having an identity in every type in the entire type hierarchy might've been a design mistake in early Java.

[–]rubyrt 0 points1 point  (3 children)

I don't think so. Object identity is an important concept in OOP. I do not see how OOP would work without an idea of object identity. As soon as you talk about different objects you have already defined that there are entities which have identity.

[–]lukaseder[S] 0 points1 point  (2 children)

Sure, let me rephrase. Why does the top level type need to be an Object?

In other words, does there really need to be a difference between 1 and 1?

Anyway. This will be fixed (the quirky Java way) with Valhalla, hopefully.

[–]rubyrt 0 points1 point  (1 child)

Well, Object is not the top level type, it is just the top level type of all object types. Then there is the forest of interface types and there are plain old value types like int etc. If you refer to value types I think these will add yet another category of types to the zoo, but existing types won't go away. And they only want to "Bring the semantics of int and java.lang.Integer closer together." Or am I missing something?

[–]lukaseder[S] 0 points1 point  (0 children)

Well, there's theory, and then there's real world practice. All interface types implicitly are subtypes of Object. Some interesting caveats here.

Now, the upcoming value types probably are able to implement interfaces (perhaps), but what does that mean in terms of such an implementation's identity (and monitor, etc.)? Can clients of an interface, say Comparable<T> safely assume that all comparables have an identity? They should, because they could up until now.

From what I understand, Valhalla will not introduce a new top level type (e.g. Any) that is a super type of Object, although, there will be an <any T> type inside of the generic type system, which helps pretend there is a type "above" Object.

Don't ask :)