`-debug` is a legitimate command since 0.13.13, but it's been impossible to use it because Bash eats it. This allows log level to be set to debug level. (similar to `-warn` setting to warn level)
Ref https://github.com/sbt/sbt/pull/2742
I've reimplemented java version detection as a bash function.
This no longer uses grep.
Also this no longer uses `?` in sed, which doesn't work on macOS.
Fixes https://github.com/sbt/sbt/issues/3873
If -verbose:gc is set, there can be gc log output in this process that
prevents the directory from being properly extracted. Rather than
blacklist possible output strings, I think it makes more sense to
whitelist the specific output line that we're looking for.
The flag can cause problems when there is another configuration
adding -Xms with a value bigger than 512M. The `java -version`
command will fail and no java version will be detected, causing
a failure in `checkJava`.
`java -version` can include an extra line of output
if `_JAVA_OPTTIONS` is set.
This commit adds a grep step before sed to harden
against this possibility.
Before:
```
⚡ (export _JAVA_OPTIONS=-Dfoo.bar; java -version 2>&1 | sed 's/.*version "\([0-9]*\)\(\.[0-9]*\)\{0,1\}\(.*\)*"/\1\2/; 1q')
Picked up _JAVA_OPTIONS: -Dfoo.bar
```
After:
```
⚡ (export _JAVA_OPTIONS=-Dfoo.bar; java -version 2>&1 | grep ' version "' | sed 's/.*version "\([0-9]*\)\(\.[0-9]*\)\{0,1\}\(.*\)*"/\1\2/; 1q')
1.8
```
Today you cannot have spaces in system properties:
$ sbt -Dfoo="bar baz" ...
It passes [-Dfoo=bar] and [baz] to java (see https://github.com/sbt/sbt/issues/2787).
This change allows you to do:
$ sbt "-Dfoo=bar baz"
which will pass ["-Dfoo=bar baz"]. And both of these two:
$ sbt "-Dfoo=bar"
$ sbt -Dfoo=bar
still work, passing [-Dfoo=bar].
Previously awk was used to grab the full Java version such as 1.8.0_91.
While this is more accurate, 1.8.0_91 is not a number that can be compared by bash, and thus JDK8 detection logics were failing.
Fixes#135
Fixessbt/sbt-launcher-package#99 formerly known as sbt/sbt#2194.
get_mem_opts() is a bash function that generates memory related
options. This change makes it return `""` the SBT_OPTS variable
contains memory-related options already.
Java is a little anti-social and attempts to lazily allocate all
of system memory, even for simple operations such as printing out
the version. This causes sbt to fail to start in environments
where resources are limited (i.e. ulimit(1)). This setup is common
on shared infrastructure such as scientific computing clusters
where because of the resource limit not being specified sbt cannot
be used.
The limit is set to 512MB which ought to be ample and is in any case
the default from sbtconfig.txt. A better patch would use the limit
specified there but it isn't clear that that is worth the effort.