Don't Use "Duplicate" button to add a new JRE/JDK in Eclipse
You may be tempted to use the "Duplicate..." button to add a new version of a JRE/JDK in Eclipse. Save yourself some potential hassle and use the "Add..." button instead. Manually copy and paste any Default VM Arguments you may have set afterwards.
The problem with using "Duplicate" is that all of the system library links remain at the old JRE/JDK after you update the "JRE Home". This can cause very strange errors, such as the following:
ZipFile.open(String, int, long) line: not available [native method]
JarFile(ZipFile).(File, int) line: 114
JarFile.(File, boolean, int) line: 135
JarFile.(String) line: 72
URLClassPath$JarLoader.getJarFile(URL) line: 646
URLClassPath$JarLoader.access$600(URLClassPath$JarLoader, URL) line: 540
URLClassPath$JarLoader$1.run() line: 607
AccessController.doPrivileged(PrivilegedExceptionAction) line: not available [native method]
URLClassPath$JarLoader.ensureOpen() line: 599
URLClassPath$JarLoader.(URL, URLStreamHandler, HashMap ) line: 583 ,loader>
URLClassPath$3.run() line: 333
AccessController.doPrivileged(PrivilegedExceptionAction) line: not available [native method]
URLClassPath.getLoader(URL) line: 322
URLClassPath.getLoader(int) line: 299
URLClassPath.getResource(String, boolean) line: 168
URLClassLoader$1.run() line: 194
Some coworkers did this, and it caused a lot of headaches trying to figure out what was happening. Practically half the dev team has tried it at one point and learned the painful lesson, and it is an easy mistake to make.
If you insist on using "Duplicate...", then there is an easy fix. After you've updated the JRE location, if you use the "Restore Default" button it will update your JRE library entries. It's still very easy to forget this step, which is potentially a lot more work than just copy pasting your Default VM Arguments. If you forget to copy those, diagnosing out of heap errors is a lot simpler.