[fauigerzigerk]

>Go's GC's support for internal pointers means it can use a pointer-and-length representation for substring references

Only if the String class is implemented in pure Java, which it currently is. But it doesn't have to be that way. Oracle could go around the Java language features and implement the String class in native code just as Go does with several builtin types. You may be right that it would be more difficult to do than in Go because of garbage collector specifics.

But I guess the real issue is a philosophical one. Is it a good idea to let the standard library use features that are not available to users of the language?

[twotwotwo]

I'm saying I think it would take GC rearchitecting for Java to be able use a pointer into the middle of the string in its internal String representation, because Java's GC, unlike Go's, is currently not built such that a pointer into the middle of anything keeps that thing "alive" for GC purposes; you have to have a pointer to the beginning. Sun made that choice that in hopes they could write a faster GC that way, I suspect.

Given that GC design, Go's two-word substring references (pointer into middle of string + count) wouldn't work; even if String were a builtin, with the no-internal-pointers GC design it would need to be at least three words (pointer to start of string, offset, count).

tl;dr of my larger point is--I think Java needed a few extra bytes/String to support substrings by reference because of how its GC works differently from Go's, and I think that explains why Java decided to remove its substring-by-reference trick while Go didn't. (And I'm not trying to say either way is worse, just trying to really grok why they're different.)