#966 tools.jar manifest not reliable for version inference
Background
In one of the educational programs I work with (the New Mexico Supercomputing Challenge), we use DrJava in a custom PortableApps.com-based flash drive configuration. In the PortableApps.com normal configuration, the 32- and 64-bit JREs are installed to /PortableApps/Common Files/Java and /PortableApps/Common Files/Java64, respectively, without the Java version in the directory names (it is embedded in an .ini file, as it is for all PortableApps.com applications and plug-ins). We'd like to follow a similar structure for the JDK, placing the 32- and 64-bit versions in /PortableApps/Common Files/JDK and /PortableApps/Common Files/JDK64 – again, without a version number in the names of the directories.
Version Inference
When DrJava is launched, the edu.rice.cs.drjava.model.JarJDKToolsLibrary.guessVersion method attempts to infer the JDK version(s), based primarily on the directory location(s) of tools.jar. If none of the enclosing directories of tools.jar contains a recognized version numbering pattern, the Created-By property is read from the manifest of tools.jar (META_INF/manifest.mf). Finally, if all else fails, the current value of java.version is used (via edu.rice.cs.plt.reflect.JavaVersion.CURRENT_FULL) .
Problem
The fundamental problem with the inference sequence summarized above is that the Created-By property of the tools.jar manifest doesn't necessarily match the version of the JDK in which tools.jar is included. For example, for JDK 1.8.0_121, Created-By in tools.jar has a value of 1.7.0_07. In general, I think it's probably much more reliable to use the current java.version value than the Created-by value, when DrJava is launched from the same JDK that contains the tools.jar file in question. When this is not the case (e.g. when examining tools.jar in a JDK that does not include the JVM under which DrJava is running), it might still be better to use a different inference method (maybe even launching the java executable with the -version parameter) before using Created-By, since the latter is unreliable.
