Java class constant pool duplicates?

Question

I have decompiled a class with javap and I'm seeing some duplicates in the Constant Pool section, like this:

 #19 = Class              #350          //  java/lang/StringBuilder
... Some other class constants here
#318 = Class              #350          //  java/lang/StringBuilder

Methodrefs refer to only one of them:

 #20 = Methodref          #19.#351      //  java/lang/StringBuilder."<init>":()V
 #22 = Methodref          #19.#353      //  java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
 #24 = Methodref          #19.#355      //  java/lang/StringBuilder.append:(Ljava/lang/Object;)Ljava/lang/StringBuilder;
 #25 = Methodref          #19.#356      //  java/lang/StringBuilder.toString:()Ljava/lang/String;
#110 = Methodref          #19.#445      //  java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;

Is this class correct according to The class File Format? I thought that every Class is mentioned just once and referred later by it's index in the bytecode part.

$ javac -version
javac 1.7.0_15

An other strange thing is in the source of the class representing the Constant Pool in javac Pool.java. This states that it will not put an object into the the pool if it is already there (with a help of a HashMap). I wonder if the equals()/hashCode() methods of these classes are implmented correctly.

Answer 1

As I understand from the JVM spec, there is no such restriction which prevents duplicate entries in the constant pool. Generally the compilers generating class file do not have duplicates. But even if the class file has duplicates, it should not affect its expected behavior.

How was the class file that you decompiled created?

Answer 2

You are right. Constant pool doesn't require duplicate entries. One class should only have 1 entry in the constant pool.

This definitely seems to be a bug. Check this out. Someone has logged this as bug and it has been acknowledged >> https://bugs.java.com/bugdatabase/view_bug?bug_id=6746955

Answer Updated:

One more thing I want to point out here is that adding duplicate entries does not make any sense because it increases the byte size of the class file and that destroys the main purpose of java class file's compactness, portability and faster network mobility. The class file should be as much compact as possible.

By the way, class file is valid because it adheres to class file format defined. But its not an ideal one.

As I forgot to, answer your second Question:

JVM assigns similar looking objects the same hashcode but still they will be distinct. JVM will never create 2 objects identical unless both are referring to same object. Hashcode is nothing but a partition system. Similar looking objects are placed into same partition so that the traversing time becomes less while searching for a particular object. Hashcode is nothing but a pointer to that small partition.

Only because it is not possible to assign distinct hashcode to each new object(because number of objects can outnumber possible number of unique hashcode creation. Please refer to possible collision in hash algorithm), you may find distinct objects having same hashcode. But here is the thing, 2 objects pointing to same reference in the memory must have the same hashcode.

So, moral of the story, JVM makes sure that two distinct objects can never be identical even if their hashcodes are.

Answer 3

A note: according to JENKINS-22525 it seems that while class files with such duplicates are technically legal, IBM's J9 VM will in some cases refuse to load their inner classes, observed with

java.lang.IncompatibleClassChangeError: incompatible InnerClasses attribute between …