Two important changes:
1. Don't change the name of the code cache dir as that would leave a stale code
cache around on old installations that were using the code cache.
2. Don't create a native libs cache dir if there are no native resources.
Everything else is mostly cosmetic and organizational.
This feature makes use of the current caching system for "code" jars. Resources marked by nresource are copied to specific cache directories, unpacked, and then the caches are added to the applications java.library.path. This "native" cache is cleaned according to "cache_retention_days", similar to the code cache.
Cleans content of each found directory when unpacking a new java_vm.
Fixes the problem when java_wm was build using standard jar.
For pack200 this remains unresolved.
Typical use case is a security patch, were a new java patch
(java_windows.jar) is put on server side and java_min_version updated
accordingly in getdown.txt
Currently the new virtual machine will be downloaded only after
a second getdown launch. This pull request fixes this.
We were already doing this for bootstrap.properties-based launches, but there's
no reason to restrict it to that. If you run Getdown with an appbase and an
appdir, it can create the app dir and download the app into it.
This enables scenarios where getdown is installed to a shared location and
users that run the app install it in their private storage area (or on a
machine local file system, or who knows).
Closes#163.
- Max concurrent downloads is controlled by a config in getdown.txt:
max_concurrent_downloads. It defaults to two.
- A bunch of thread-safety problems were fixed.
- While in there, I revamped the downloader to be less crufty from years of
ad-hoc requirements accretion.
- I disabled the Channel.transferFrom based download change because it prevents
fine-grained feedback (and abort checking) from taking place, and it doesn't
handle failure cases. Maybe we'll clean it up and re-enable it in the future.
Michael Bayne