This release cycle makes no sense to me. We haven’t even finished migrating all our components to compile with JDK8 yet, though they’ve all been running against it for a while now. We’re barely even discussing moving to JDK9 at this point. What company with a reasonably large software base is going to keep up with a six-month release schedule? 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?
>This release cycle makes no sense to me. We haven’t even finished migrating all our components to compile with JDK8 yet
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.
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.
"Contract won't or shouldn't change" seems unrealistically idealistic to me. Java migration - or any platform for that matter - is not just migrating its language features but also its ecosystem - runtime, VM, GC, frameworks.
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].
Enterprise Java is mostly about writing glue code that combines dozens of libraries and frameworks. How can you tell (without testing) if tens of millions of lines of code in those libraries are not doing anything stupid, like depending on implementation instead of contract?
The most important contract, the JVM spec, is really good in Java, and that makes up for almost everything. Javalang and the standard library is generally very good about maintaining backward compatibility (almost to a fault, some would say). Of course, there is code in the wild that depends on, for example, the com.sun packages and so on, and that extend the JVM using JNI - in those cases, all bets are off. But that was always true, and I'd argue that such contortions are generally as ill-advised as they are rare.
So, yeah, I think a faster release cadence is a good idea! Upgrading the runtime should be as simple as upgrading any other dependency.
This is my only problem with it. I can’t imagine it stays like that. I feel like there has to be at least a year of overlap between release of one LTS and deprecation of support for the previous one. Or at least a commitment to continue with security patches for longer (while stopping bug fixes and enterprise support)
You'll be OK as long as you're dropping off suitcases of money at Oracle's door, but currently it appears that freely available fixes/security updates will cease as soon as the next LTS is released.
If that were so simple. What if your software gets deployed on an application server? If you upgrade, you need new support contract, this costs money plus leads to possible deployment/config changes, for instance going from JBoss 5 EAP to JBoss 6 EAP is not a pleasant experience as almost all configuration was radically changed.
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 one is forcing anyone to upgrade. What worked on Java 8 3 years ago, will work on Java 8 in 17 years. If your team have extra requirements (audit, certification etc.), it seems it sells enterprise software. All those things cost money, but I assume you also charge money. So, what's exactly the problem? It is a bit naive to expect to get ultra stability for free from your suppliers, but charge top dollar from your customers...
By only providing fixes and security patches for a few months -- after that you need to move to the next version (with all that entails testing and adapting wise for large codebases), or you pay for enterprise support and get support for years.
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.
Not sure that’s how it works. You don’t really need to update anything. Ubuntu runs on y monthly releases, for instance, and sees plenty of enterprise usage. The Linux kernel itself is updated as often, if not more. Google Chrome updates all the time. Ruby does yearly major releases, as do other languages. Go does six months, I think.
Teams in charge of software release whenever they want or can, clients are free to use whatever version whenever they want.
The problems only happen with breaking changes - and I haven’t seen a single case of Java breaking backwards compatibility (not counting cases where users intentionally used or relied on private implementation details).
If you have written your regular enterprise web service you will probably not have very complex code (I'm not talking about business logic, but language features).
But then you are using a 1 year old framework (if you're lucky) that depends on a version of library X that is 2 years old that depends on a 3 years old library etc.
At the end of the chain you have a library that does low level stuff (bytecode instrumentation for example) and is a few years old. That is what may give you problems, and often the only practical solution is to update to a newer version of the framework, which can be quite expensive.
I'm curious, how large of a company did you work for such that you were able to easily upgrade your JDK version?
Because I worked at a fairly large tech company and every one of our applications required some amount of manual intervention beyond figuratively switching all the "7"s to "8"s. That's despite the fact that hardly any of them were doing anything particularly complicated, and absolutely none of them were doing anything involving hidden com.sun APIs. I think it's just a consequence of such a large build system.
Yeah the reality of the situation is that it's never as straight-forward as just recompiling with the latest JDK.
From my experience it wasn't generally code written in-house that'd cause problems (but sometimes it was), it was dependencies and transitive deps that required the older JDK (sometimes they relied on old bugs or old tooling, sometimes they just couldn't be recompiled on the new JDK for whatever reason).
Build tools that relied heavily on JVM internals often couldn't upgrade for some time. Third parties integrating with your software and the new JDK brings a slight change in it's SOAP/XML/ser-deser stuff etc.
That said, Java has been the best at backwards compatibility that I've tried, given it's popularity, and most of the pain was in the early days (like anything I suppose, see the Javascript world atm). Microsoft's offerings probably do backwards compatibility well, but then you get all the rest of the technical- and wallet-pain that that environment brings with it.
For instance, if you depend on an old version of the Spring framework, using some Java 8 features (like lambdas) will break, since it generates bytecode Spring doesn't understand. Compiling as Java 7 prevents inadvertent use of these features.
Java 8 made some changes to type inference that can, in certain edge cases, cause generic method calls to bind differently. While it’s _mostly_ backwards compatible, it’s not entirely.
I think it makes total sense to have the language evolving on a scheduled basis rather than stagnate.
If your company is only discussing moving to JDK9 now, what difference does it make that JDK10 is out? If you are using the free version, there is no real support. If you are a paying customer, Oracle will support you to the end of time while wringing every last cent out of your company.
What difference does it make if the language keeps evolving? Do you expect the entire world to revolve around you and your company?
Given that your company is still on JDK7, and is already saying a "fuck you" to new features, I don't think anything will change for you at all. You can continue ignoring newer features, but that doesn't mean everybody should. If they find value, they should have an option to move fast.
This is the same strategy that wrecked Eclipse and Firefox. Every 6 months is just too quick for most people to feel comfortable, and will cause fragmentation as the 3rd party ecosystem updates things at different rates.
They broke compatibility with v57 exactly for that: to make continuous small changes. The previous situation was untenable since there was no API for extensions, the extensions could just go through Firefox internals and change at-will whatever they wanted.
The whole point of WebExtensions is that they won't need to break compatibility after this huge leap.
FireFox constantly broke all my extensions with just about every minor update. It was maddening. After being a die-hard FireFox/Netscape/Mozilla user since the 90's, I finally gave up a few years back and switched to Chrome. I can't recall a single time since then when my browser or extensions stopped working because of any update, not just a minor one.
