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.
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?
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.
This is why I like Linus' stance in this case.
This is the first time that has happened to me in nearly 20 years of using java.
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.
It’s just now Java gets to iterate and improve more frequently and regularly.
Regardless there are still LTS releases (every 3 years) for people who lean more conservative.
https://stackoverflow.com/questions/34659055/java-8-incompat...
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 :)
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.
There are many examples of migration problems for any platform - just have to google it. When information that can challenge our assumptions is just a google search away, I don't see why one should hold on to blind faith in idealistic assumptions. Here's one writeup of a system whose performance suffered simply by migrating to Java 8 without involving any code changes [1].
[1]: http://engineering.indeedblog.com/blog/2016/09/job-search-we...
So, yeah, I think a faster release cadence is a good idea! Upgrading the runtime should be as simple as upgrading any other dependency.
Are they dropping support for the latest LTS just four month after releasing a new LTS? That sounds a bit harsh.
What if part of your application is audited and certified by some regulatory body, when you upgrade, you need to go through the process again.
Java value is stability, you can assume your software will run for 20 years without touching it.
No, but they are restricting them from updating as easily as before -- unless they cough up dough.
Before you could go to any version and expect it to be supported for years.
Now, if you dare go to some version above 8, you're supposed to either pay (for long term support), jump directly to the next version after a few months, or stay without security fixes.
(Or go OpenJDK and screw them).
Why is it Oracles fault that you keep your components on Java version that has been deprecated and support dropped 4 years ago?
>What company with a reasonably large software base is going to keep up with a six-month release schedule?
What? No. That's now how it works. Every 3rd release is LTS and it support time is between 6 and 11 years as so far discussed. Java8 won't be supported after January 2019, Java11 (LTS) will be release in September this year.
> Java isn’t a web browser or some other user application. Who would even _want_ to spend the kind of resources required to constantly be testing new JDK releases?
You're not supposed to be testing it. You're supposed to write code to a contract, contract won't or shouldn't change. If you write code that follows implementation instead a contract (let's say you relay on HashSet order - I've seen it), it's your fault. We always make sure we write code that follows the contract. We're migrating our code base to Jigsaw now, after Spring 5 and SpringBoot1.5 were release with updated dependencies. If Spring and Tomcat teams made it available earlier, we would be on Java9 months ago.