Thanks for the feedback. Let me give you a bit of explaination to help you understand the decision to bundle a jre in the installer. Since the installer is Java-based, it is dependent on an appropriate jre existing on the user’s machine, if one is not bundled. Because we found this was often not the case, we made the decision to bundle a jre, initially just for the installer’s use, so it would always be able to operate properly. Once we found that improved the installation experience, it makes a lot of sense to leave that jre so that MyEclipse can be assured of also running correctly out of the box. Please note though that the jre that is installed is *only* used to start MyEclipse and is installed under the MyEclipse install root. It is not installed for system use and no PATH variables are updated. This install technique is very similar to what almost all commercial application servers do and is done for the same reasons, to ensure that the product will operate correctly upon first usage.
As far as the “JDK trust” issue goes, the installed jre is only used to run MyEclipse. You are still able to install a different version in another location and make it the default installed JRE within MyEclipse so that all your projects are compiled only with the jre you prefer. In fact, that’s exactly what we do internally.
So, the shipped jre is installed only to start MyEclipse to ensure correct operation and you can easily install a different jre for use by your projects. Can you give us a little more insight in why shipping a jre is of specific concern if this is the case?