Strings Just Got Faster

I've seen Java described as made for companies to be able to rotate out mediocre programmers as efficiently as possible without letting them mess things up easily, and it makes a lot of sense from that perspective. Barebones semantics to the point of being Spartan (can't even define your own operator overloads), easy to take another class and copy it with small modifications but not mess it up for anyone else (inheritance)..

Then there's C# which most anyone who's enthusiastic about software dev will find far nicer to work with, but it's probably harder for bargain basement offshore sweatshops to bang their head against.

You can use the JVM without needing to use OOP e.g. Scala, Clojure, Python, Javascript, Ruby etc.

Then you can get to benefit from Java's unparalleled ecosystem of enterprise hardened libraries, monitoring etc.

A good starting point is Joshua Bloch’s Effective Java. He shares some stories there from Java’s early days, and - at least in passing - mentions some aspects of the String class’s history.

> Would you mind sharing some suggestions/pointers?

I would, but unfortunately I got a NullPointerException.

I suggest you try Rust instead; its borrow checker will ensure you can't share pointers in an unsafe manner.

> used as a static constant

Yes, but remind people it's not static in the sense of being associated with the class, nor constant for compile-time purposes.

Perhaps better to say: A stable value is lazy, set on first use, resulting in pre- and post- initialization states. The data being set once means you cannot observe a data change (i.e., appears to be immutable), but you could observe reduction in resource utilization when comparing instances with pre-set or un-set values -- less memory or time or other side-effects of value initialization.

So even if data-immutable, a class with a stable value ends up with behavior combinations of two states for each stable value. Immutable records or classes without stable values have no such behavior changes.

But, writ large, we've always had this with the JVM's hotspot optimizations.

For String, it becomes significant whether hashcode is used when calculating equals (as a fast path to negative result). If not, one would have two equal instances that will behave differently (though producing the same data), at least for one hashcode-dependent operation.

So every time you take the hash of a string you leak 4 bytes of memory???

I assume it's static in the context of it's containing object. So, it will be collected when it's string is collected.

But this is also achievable with static init methods on records and value classes, right?

  record Rational(int num, int denom) {
      Rational {
          int gcd = gcd(num, denom);
          num /= gcd;
          denom /= gcd;
      }
  }

> It's similar to something like lateinit in Kotlin, except on the JVM level.

What level are you suggesting lateinit happens at if not on the JVM?

I've just tried to change a field of an instance of a record using reflection, and it's not possible, even with setAccessible(true).

So, the problem here is that you're thinking of "cryptographic properties" as only the "cryptographic hashes" such as those built with the Merkle–Damgård construction (SHA-512/256 being the one you might reasonably pick today)

But, it's actually desirable to have some cryptographic properties in a faster one way function for making hash tables. Read about SipHash to see why.

Because Java didn't (and as others have discussed, now can't) choose otherwise the hash table structures provided must resist sabotage via collision, which isn't necessary if your attacker can't collide the hash you use.

The thing is, even it being used just in collections can lead to DOS, if the attacker can control the string contents, and selectively choose strings that your hash table stops being a hash table and turns into a linked list.

Even in collections, an unstable hash is desirable -- to avoid denial of service attacks caused by attacker-controlled hash collisions.

For example, Python back in 2012: https://nvd.nist.gov/vuln/detail/cve-2012-1150.

To be more precise, Java initially uses a linked list for nodes within a bin. If the number of items inside the bin crosses TREEIFY_THRESHOLD (which is 8), then that specific bin is converted into a RB tree.

This is detailed in implementation notes comment here: https://github.com/openjdk/jdk/blob/56468c42bef8524e53a929dc...

They aren’t and it’s quite unfortunate that the empty string hashes to 0 so it will have to recompute every time although presumably it is quick to compute the hash of the empty string.

The bucket is computed from the hash code and the size of the array, but that's not necessarily the index. If there are no bucket collisions, then index==bucket and this works out. But if there are bucket collisions then the index will be different from the bucket. So you still need some computation IIUC. And there's no way to memoize that result, since memoization would require a hashmap that has the exact same characteristics as the original hashmap.

I guess a @Stable attribute on the array underlying the map would allow for the elimination of one redirection: in a mutable map the underlying array can get resized so its pointer isn't stable. With an annotated immutable map it could be (though IDK whether that'd work with GC defrag etc). But that seems like relatively small potatoes? I don't see a way to "pretend the map isn't even there".

But it doesn't support using fancy unicode quotes as string delimiters.

This implies they have their own String implementations? I wouldn't be shocked to find out that is the case, but it would surprise me.