Previous value of 8M caused JVM to crash on servers with more then 40G of RAM
Tested on databases servers up to 1.5T of RAM, 12M seems to be sufficient
* dirname containing base directory of java
* e.g. java binary is `${::java_default_home}/jre/bin/java`
* dirname containing `libjvm.so`
* Most people will use this for LD_LIBRARY_PATH
The other method for running which java doesn't work on OSX, as java is installed as an empty shim when not installed in the base OSX image:
```
vagrant:~ vagrant$ java
No Java runtime present, requesting install.
vagrant:~ vagrant$ /usr/libexec/java_home --failfast
Unable to find any JVMs matching version "(null)".
vagrant:~ vagrant$
```
We can use the `/usr/libexec/java_home --failfast` command to check if
java is actually present first.
Originally-by: Peter Souter <peter.souter@puppetlabs.com>
Add info about OpenBSD support to README.md and metadata.json
Add a note about OpenBSD java_version fact to README.markdown.
Fixup wording on context in one of the java patch level regression tests.
No mentioning of OpenBSD in metdata.json
Cleanup wording of context as suggested by @elyscape
update contexts as suggested by @elyscape
Uses the `java_version` fact and gets the patch level by splitting after `_`
This would be useful if you want to make sure you're not accidentally downgrading the version of Java to a lower patch level (I've noticed some package managers don't notice this too well)
Adapted from the many found on Github, simply runs `java -version` and strips the results. From what I can find there aren't many edge cases for the result `java -version 2>&1` could return, so this should be fairly compatible.
