5 ms·
I can't agree with this analogy. This is not a defective user implementation of hashcode; it is a defective platform implementation of equals (and starts with,
by orra 3y ago
I can't agree with this analogy. This is not a defective user implementation of hashcode; it is a defective platform implementation of equals (and starts with, etc.).
- pshirshov 3y agoThis is a broken user code written without any JMM understanding.
- thfuran 3y agoA proper implementation of hashcode can return nonsense if you mutate the object during hashing.
- orra 3y agoSure, but here we're not mutating the object during the String.startsWith() call. Hence I'd say it's a TOCTOU bug in String.valueOf().
- thfuran 3y agoThis is pretty much the same as breaking a Map by mutating a key during insertion.
- pshirshov 3y agoPrecisely. Is it good that this can happen? No, Java must be more like Scala and push immutability as sane default. Is it a bug? No. Is it possible to "fix" the language and the VM at this stage? Yes, but that would be a new language and new VM. So, that's not going to happen.
- pshirshov 3y agoAgain, this is not a bug. There are many, way too many places in standard library which are thread unsafe. Some of these are actual bugs, but not this one. If Java originally moved in Odersky's direction that won't be the case but now it's way too late to point fingers at these "quirks". In order to properly fix these issues the whole standard library has to be redesigned around immutability and, probably, immutable arrays must be supported at VM level. This is not going to happen. But it's specified that standard Java classes are thread unsafe by default. So this is a specified behaviour.