Why Object.hashCode() does not follow Java code convention [closed]

Question

Is there any specific reason, why hashCode is the only public method of Object class which does not follow Java Code Conventions recommended by Sun and later on by Oracle? I mean they could name it toHashCode() or getHashCode() or createHashCode() right?

EDIT: I talk about Code Conventions for the Java Programming Language ( oracle.com/technetwork/java/codeconvtoc-136057.html ). These conventions are referenced in Oracle's book 'OCA Java SE 7 Programmer I Study Guide (Exam 1Z0-803) (Oracle Press) - Liguori, Robert'

In the document we can read as follows: "Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.".

AFAIK hashcode is not a verb.

Answer 1

I think it does follow conventions. It all depends on which convention you're talking about.

The OP is specifically interested in the Code Conventions for the Java Programming Language, and the conventions for method names are covered in chapter 9. First, it should be noted that this document is no longer maintained, and contains a large caveat:

... the information itself may no longer be valid. The last revision to this document was made on April 20, 1999

Of course, the hashCode() method predates 1999 so we can refer to the document to see if the method in question violated the conventions at the time. The document states:

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

With regard to hashCode(), there is no disputing that it is mixed case with the first letter lowercase. However, the OP seems to be of the opinion that it violates the convention that methods should be verbs; the implied assumption is that "hash code" or "hashcode" is a noun.

Before passing judgment, let's look at the third part of the convention: the first letter of each internal word [is] capitalized. If you briefly assume that the original authors followed these conventions, then the capitalization of hashCode() indicates that its authors considered "hash" and "code" to be separate words. If you treat them separately, the word "hash" is a verb in English. With that interpretation, all parts of the convention are met.

Admittedly, the term "hash code" has become common jargon among (at least) Java developers and is often treated as a noun -- probably in no small part due to the name of this method in the first place. (Chicken v. egg?) But only the original authors can speak to their intent.

---

In my original answer, I used the JavaBeans conventions as an example:

A bean is a Java class with method names that follow the JavaBeans guidelines. A bean builder tool uses introspection to examine the bean class. Based on this inspection, the bean builder tool can figure out the bean's properties, methods, and events.

In JavaBeans, properties are accessed via a "getter" method, i.e. the "foo" property is read by calling getFoo(). However, the hashCode() method is a technical requirement imposed by the Java language on all subclasses of Object but is not generally a property of the "business logic" that the object represents. If you write a class to represent fruits, it would have properties like getColor(), isSkinEdible(), etc. If not for Java's technical requirement, you would probably not consider writing a method like getHashCode() because... have you ever found a real, live banana with a hash code?

If hashCode() were named getHashCode() then, for this convention, JavaBeans would have to special-case it in order to ignore it. Or it would always inspect that "property" for what commonly has little use in the main logic of your program.

---

I can't cover all possible conventions in this answer, but I have these thoughts on the other examples given in the question:

• createHashCode() - I would not use this, even by convention, because hashCode() returns an int (a primitive) and they're not created like reference types (Objects) are. I think this would be the wrong verb.

• toHashCode() - To me, this represents a conversion. But that's not what hashCode() does. If foo.hashCode() returns 42 I should have no expectation that 42 is in any way a representation foo. It was computed from information about the foo instance, but there's no other real correlation. Plenty of other instances (of many classes) could return 42 so it's not a stand-in or analogue for any of them.

Answer 2

The hashCode() method was specified before there were conventions.

Also, the convention is for naming Java Bean "properties," to facilitate wiring together beans in a design tool and assist in other forms of automation. It's unlikely that you'd need the hash code to be exposed as a property in these situations. In fact, because getClass() does follow Java Bean naming conventions, it requires a special case in many such tools to exclude it from the list of object properties.