I think it's interesting to discuss how many are stuck on java8. It was a long time many of us were stuck on java6 or 7, and finally got up to java8. But then when 9, 10 and 11 came no one made an effort to upgrade. Why? And now we're at 15 and people are starting to feel the heat.
We only migrated our main service from 8 to 15 a month ago (AWS deprecation), but still have lots of 8 code laying around (luckily some of the container-features were backported)
> I think it's interesting to discuss how many are stuck on java8. [...] But then when 9, 10 and 11 came no one made an effort to upgrade. Why?
A lot of things broke in Java 9, which was short-lived (both it and Java 10 lasted only six months each), and then Java 11 broke many other things (for instance, it removed all of J2EE). As late as last year, I was still seeing changes in libraries to fix issues with Java 9 or later. It's not that no one made an effort to upgrade, it's that it was a lot of effort, and often required upgrading to later versions of libraries, which have their own breaking changes.
In my experience mst of these changes are simple to add to your projects pom or build.gradle. For instance the removal of the jaxb xml runtime is a simple 1 liner to your project:
Speaking from personal experience, the creators of most of the recent JDK versions have made very poor efforts to explain the changes, it's mostly just a list of RFC type documents, and who has time?
An example of something that compares favourably would be Go, where they always blog about the changes, and there's easy to find official language documentation (and not just autogenerated API docs).
Have you tried for example the linked article with all the JEPs listed with lengthy descriptions? And with links to relevant mailing lists if it didn’t satisfy your curiosity?
I just yesterday took the time to go and read through them. And I still consider it awful UI.
- A list of links is not a summary. The list is too short, reading every individual linked document is too long. The format of JEPs tends to bury the lede. As such it feels like wading through mud.
- Changes that affect the programmer experience are mixed at random with changes that affect internal details of the implementation.
- Changes that introduce experimental features are mixed at random with changes that are final.
