setup-java should search in /usr/lib/jvm as well as the tool cache about setup-java HOT 2 CLOSED

Adding a check to see if the desired version is pre-installed could make sense,a nd may reduce traffic for many common cases (latest 8, 11, 13) for several weeks at a time. But it's important to keep in mind that java packages get updated quite frequently, and potentially more frequently than the OS images do, and that in the days or weeks immediately following a Java quarterly update, the OS-image-pre-installed java update versions is unlikely to match what e.g. "11", "8.0.x", "13", or "14" mean in semver terms: E.g. 7.0.262, 8.0.252, 11.0.7, 13.0.3, and 14.0.1 all came out on April 14, 2020, and they will all rev again on July 14 at the latest...

We could try to separate the specific version determination from the download of the determined bits. E.g. once the desired version has been determined (by scanning the CDN for semver-matching things and choosing one), we could see if the exact same package we want is already in /usr/ib/jvm, and skip the download if it is... This would certainly help reduce download bandwidth if the OS images get updated with versions from the same CDN in a timely manner, but will also likely leave traffic spikes in the days that follow each quarterly update, until the OS image catches up. It also has the downside of not addressing older versions (many tests like to nail down a specific update version to test against consistently) and rapidly changing versions (e.g. the EA builds that rev as often as once a week).

An alternative (and more time-robust approach IMO) is to look to incorporate actions/cache in some way. This would create much more consistent caching (which would work even in the days following a quarterly update, and even for rapidly changing packages like the current 15-ea packages), and would likely reduce the download traffic loads during peak times (right after updates) better than an attempt to sync up the contents of the OS images would. It would be great if action/cache was directly leverageable from other actions in some way. But until it is, we can either make direct use of the cache package in the toolkit.

from setup-java.

Hello everyone. We moved our precached java versions to /opt/hostedtoolcache/Java_Adopt_jdk directory on hosted runners. Recently we released setup-java@v2 and new task version will be able to consume pre-installed java version. You can see migration guide from v1 to v2 here. If you have any concerns feel free to reopen the issue.

from setup-java.