This makes sense given that we already support app_id-prefixed apparg
parameters, and one might want to configure the JVM specially for different
apps from the same installation.
Note: unlike apparg, app_id-prefixed jvmargs are appended to un-prefixed
jvmargs rather than replacing them. I think this makes sense because you
probably want to specify standard JVM args and then maybe tweak a thing or two
for your other app. This is also backward compatible which is usually a good
thing. It does mean that it's harder to "undo" a jvmarg set for your "default"
app, in such cases you'd probably have to not have a default app and instead
identify all of your apps with app_ids.
This relies on the existence of a 'release' file in the top-level of the
unpacked JVM. If no 'release' file exists (or it can't be read) then we fall
back to the old behavior which is to assume that an unpacked JVM meets the
app's version requirements.
This also assumes that the java_version_regex configured for the app is capable
of parsing the version string in the release file. The release file appears to
contain a string that matches the system property 'java.version', so if you are
doing version shenanigans and using 'java.runtime.version', you need to do one
of two things:
1. Make sure your regexp can handle missing bits and that the lack of said bits
doesn't hose your version checks. For example, if you need 1.8.0_42-b15 and
your version regexp turns that into 108004215, but the release file just
contains 1.8.0_42 which your version regexp turns into 108004200, then you're
going to have a problem. But if your minimum version is some previous patch
release (say 1.8.0_25-b32) and the custom JVM you ship is 1.8.0_42, then you'll
be OK because 108004200 > 108002532.
2. Create your own 'release' file in your custom packaged JVM (or modify the
existing one) which contains a line with the following syntax:
JAVA_VERSION="VVV"
where VVV is the full version string that your regexp expects. It will be
extracted and parsed with your regexp, and everything will be peachy.
For example:
java_version_prop = java.runtime.version
java_version_regex = (\d+)\.(\d+)\.(\d+)(_\d+)?(-b\d+)?
Note: double backslashes are not needed in getdown.txt.
This preserves existing functionality, but accomplishes it with a general
purpose method that can parse any Java version string, given a regular
expression that matches all the number parts (which have to be in most to least
significant order).
This unfortunately relies on _app.init() happening *inside* detect proxy in the
particular code path that results in failed proxy detection. I wish app.init
wasn't such a twisty maze of spaghetti, but that ship has long since sailed.
This allows one to bootstrap a Getdown install with no files at all. You don't
get a very sexy UI during the first install, but you can make something
non-horrible with a background color and a small window.
Michael Bayne