What a horrible wart lingering from the early days of the Internet. Note to
future designers: please do not express configuration using a Turing complete
language.
Thanks jenriq for getting the ball rolling on this.
Closes#196.
Null tolerance is a plague. I wish `String` did not admit nulls and we had to
use Optional<String> for potentially null strings, but Java will forever be
cursed with the billion dollar mistake.
- remove hardcoded 60 seconds timeout during verify, as with pack200
this may fail on slow systems
- introduce new config "timeout_verify" with 60 seconds default
- handle timeout with aborting the launch
This also makes the use of a Proxy instance explicit in the Getdown code,
rather than trying to thread things through the proxy-related system
properties.
It introduces a ProxyAuth SPI which allows an app installation to save proxy
credentials in whatever way it deems fit. Otherwise the credentials are unsaved
and the user effectively has to enter them every time Getdown attempts to
access the internet.
This is obviously a terrible design, but there's no good (cross-platform) way
to securely store a username and password. So anyone using this feature is
likely going to need to provide an implementation of ProxyAuth that does
whatever auth storage they deem appropriate.
Adapted from PR from @ThomasG-AI, thanks!
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.
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.
Michael Bayne