Because you won't have to schedule full compatibility testing of your app in order to find out that there were breaking changes in the newest JDK version that r

Because you won't have to schedule full compatibility testing of your app in order to find out that there were breaking changes in the newest JDK version that require the user to fix the app. You can just not update the major version of JRE for a long time. The JRE will still be updated with security fixes and bugs, but no breaking changes should be introduced. Developers can focus on extending functionality instead of maintenance and porting the app to new JRE. Devops can focus on different things than adapting the environment to the new requirements that were broken in new JRE major version. Product managers don't need to create another spreadsheet columns to mark compatibility issues. The problem with "most libraries keeping their code compatible with the newest JRE version" is that most projects use a library that is not kept up-to-date with the newest JRE version. Often that library is the library which has no alternatives. Also switching libraries is rarely a trivial thing to do. Using bleeding edge software also means that we participate in "beta" testing. Company-oriented human resource management would suggest that the resources the company spends should be about the needs of the company, not some thirdparty product.