[1.8] Kill me please!

[Ernio]

I wrote essay just a second ago, but lemme 1st ask one thing:

 

private final HashMap<String, String[]> args = new HashMap<String, String[]>();

 

Is this shit consistent?

 

this.args.hashCode()

 

Everything from docs tell me it is:

* Map.hashCode() is sum of all hashcodes of entries in map

* String has consistent hashCode since JVM 1.2 (I think)

* Only thing left is String[] - which I THINK is also consistent?

 

Anyway - 6 SAME (edit: their elements and order of adding) maps like this, with same input, 3 on server and 3 on client logical side - each of those return different hash!

Also - if I'd loop them and put their elements into NBT the NBT will be equal, damn - even ordering is the same.

 

Java masters - teach me. (Today I've travelled (~4hours) through 7 inheritance hashCode() methods and finally arrived where they start being different - and that is on this situation above).

[Abastro]

Did you check if they are equal by equals method?

[TheGreyGhost]

Hi

 

Without thinking about it too hard, I would say that the hashcode of a String [] might just be the object reference, i.e. a shallow hashCode.  This will be different for each instance of the String [] regardless if all the Strings in the array are identical.

 

If this is important to you, perhaps you could replace String [] with a container class that does deep hashCode on the Strings it is holding.

 

-TGG

 

[Ernio]

At point of writing this I was going to sleep (no time to check), but yeah - Object[] was the shit.

 

Until now, I always preferred (in my mod's parts of code) String[] to any List<String> - reason is obviously less memo and fact that those were used with commands and configs:

execute(ICommandSender ics, String[] args)

ConfigCategory#getStringList()

 

Anyway, spent about 2h to convert like hundreds of fields and methods to ArrayList<String>.

 

Thank for reassuring. (that was my hashing problem).