The strategy that worked for us is to decide which versions of the JRE we will support. We do this by looking at the platforms used by our users, the version-specific features of a particular JRE that we would like to use, and the release dates of the JRE versions. All this is done in close consultation with our customer support department. (Of course, ceteris paribus, we prefer newer versions, since they usually have bug fixes, optimizations, security updates, etc.)
Then it becomes a contribution to our QA process. Our testing efforts should cover all versions of the JRE that we support.
Finally, we use the ability to specify specific versions of the JRE in the JNLP file when deploying our application to ensure that clients who try to run our application with an unsupported version get a “bad” experience (with a useful message on how to get the correct version of the JRE) rather than mysterious setbacks in the future.
We try to minimize incompatibilities in order to avoid undocumented APIs ( sun.misc , etc.).
Explicitly checking the current version of the JRE from your code should only be considered as a last resort to working with a known bug in a specific version of the JRE. If such an error is detected early enough in this process, we prefer to simply remove this version of the JRE from the list of supported versions.
Matt mchenry
source share