Linus may be occasionally obnoxious but I believe his "don't break user space" mantra is a significant reason why Linux is so popular. A similar attitude guided Windows development (until Vista) and it dominated the desktop world. In comparison your attitude seems user hostile to me. No "user" is interested in comparing theoretical specs with the behaviour of the reference implementation. They just want a tool to deliver solutions that work.
For the first time in years, I'm looking at alternatives to Java for my next project. Java was always seemed to offer a pragmatic compromise in terms of language design and features and the availability of developers and libraries. Rapid breaking releases destroys most of the value of Java for me.
>Rapid breaking releases destroys most of the value of Java for me.
Almost nothing is broken in Java. Jigsaw modified who to use reflection to access data in an insecure manner. You should not be doing that in the first place for obvious reasons. But the code that was using reflection still works, you just get a warning when starting an application. That's all.
>No "user" is interested in comparing theoretical specs with the behaviour of the reference implementation
So you're probably not going to write any code in any strong-typed programming language, all of them have some kind of contracts you should/have to follow.
Do you know that Oak source code (what Java was called before) still compiles and runs in Java10?
I'm not sure how you can confidently assert that "almost nothing" breaks with Java 9. Maybe we were just unlucky that the very first application (a simple less than 20KLoC JavaFX Gui) we used to test upgrading to Java 9 broke immediately. But actually googling "Java 9 breakage" returns a ton of results so I guess our experience wasn't an outlier.
You are just repeating that it's fundamentally the user's fault because they "should not be doing that". A properly designed tool prevents incorrect usage. If a version of Java allows you to do something and that something proves to be very useful to GET THE JOB DONE, then I'm with Linus - the blame is not with the user.
For example, there was simply no alternative to using Unsafe in the past to get reasonable Java performance for certain task. The fact that it was there allowed me to resist the pressure to move a significant part of our codebase to C++. Of course we "should not be doing that" (using Unsafe) but the alternative was abandoning a large existing code base and hiring a bunch of C++ experts or retraining our existing developers or spending 10 times as much on our server capacity. Using Unsafe was a simple pragmatic decision. You cannot say it was "wrong" without knowing all the factors that went into the decision.
There are long term support releases. I suspect that most enterprise places will end up using only LTS versions.
The real killer with the six month releases is not that they're every six months. That's doable. The killer is that they have zero support (even for security issues, I believe) once the next release comes out. As a result, you have to be ready to switch immediately. If you could upgrade to Java 10, then wait twelve months and go to 12, it would be less painful.
Yeah, the lack of overlap in support between LTS releases is the real killer. I predict that in 5 years there will be few people using the Oracle JVM. People will migrate to the JVM supported on their OS (for example, RedHat supports OpenJDK for the life of the OS as part of their OS/middleware offerings).
If I read that correctly, the “breakage” is a bug fix, as that particular Java 7 compiler isn’t behaving according to the spec. You can argue that breaks backwards compatibility, but in the smallest, most innocuous way possible.
My understanding after reading the answer to that SO question is that the behavior in 7 was a bug. New releases of javac aren't required to be bug-compatible with previous releases.
> In comparison your attitude seems user hostile to me.
Who care about his attitude? Is he the BFDL of Java or something? :)
On a separate note, good luck moving away from Java to a platform with better backwards compatibility! There's a reason Java is used for enterprise software, it's one of the best platforms for keeping compatibility. It's probably not perfect, but the others are just worse :)
I guess he cares (he spent the time expressing it in writing) and I care (I took the time to respond) :)
Also I'm not considering alternatives just because Java 9 broke stuff. There are lots of other reasons why Java irritates me but I felt it was still a winner when you balance up all the factors. But if backward compatibility is no longer going to be prioritised, then this shifts the calculation so that it's at least worth it, in my mind, to evaluate alternatives. So we're going to try Kotlin on a fairly small self-contained project.
For the first time in years, I'm looking at alternatives to Java for my next project. Java was always seemed to offer a pragmatic compromise in terms of language design and features and the availability of developers and libraries. Rapid breaking releases destroys most of the value of Java for me.