Hacker News Reader

Comment by MH15 | Hacker News Reader

It's fine to break backwards compatibility when introducing an entirely new feature across a major version, actually. What's even the point of a major version bump?

View on HN

Not everyone uses semver, although in any case Java "major" versions are actually a continuation of what was called the 1.x line -- they gave up on writing out the "1." a couple of decades ago. They're semver minor release, not semver major.

Plus, prepending the string with `STR.` changes the syntax entirely. Those strings are still invalid if you don't prepend `STR.` (which is another thing I hate, but not quite as much).

In C#, the string `"""Hello world"` is invalid, but `@"""Hello world"` is, because double quotes are valid with verbatim string literals.

There's plenty of languages that have your attitude. Java doesn't. Feel free to use one of those other languages.

Oracle has broken compatibility between versions before, at least in the runtime. URL Decoder's constructor was taken private after JDK 11:

https://docs.oracle.com/en/java/javase/11/docs/api/java.base...

https://docs.oracle.com/en/java/javase/17/docs/api/java.base...

There was a nice long deprecation period between those versions, where everyone using it got a warning. And then, when it was finally removed, everyone using it got an error, and they were forced to change their code. By contrast, a string literal could silently change meaning if it used syntax that was previously valid in strings. This is the exact same reason JS chose to require backticks to delimit interpolable strings - because otherwise existing string literals could silently change meaning.

Not if string literals are prepended with `STR.`. Old strings won't be affected

I hadn't caught that this was required, but then it'd lock them out of removing that requirement. Plus it'd complicate the parser, to have there be two different kinds of string literals syntactically.

Reply on news.ycombinator.com