Still on Java 8 at work :-/
You're also missing out on var and switch expressions, which are very visible features (as are records and instanceof patterns), so the difference should be obvious between a Java 8 codebase and a Java 15 one.
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)
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.
runtimeOnly 'org.glassfish.jaxb:jaxb-runtime:2.3.2'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).
- 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.