I wrote an portal application to control the environment for a third party application, the portal uses a JRE version that I supply with it, this was to ensure that users are using the same JRE so any issues can be limited to one version of Java. The only piece of the application that I could not specify the JRE version and path was for Internet Explorer. Please keep in mind that I do not control when the system JRE is updated or not, this is pushed to our systems and the latest JRE would be enabled automatically. I wanted to be able to dynamically add and enable the version of the JRE that Microsoft Internet Explorer uses for applets. So I was digging around recently and if I have the next-generation plugin enabled I could programmatically update the deployment.properties file prior to launching Internet Explorer(assuming I have closed all prior instances of IE that were running) to add and enable a version of the JRE which I choose to use. When I launch IE and run an applet I see that it is using the JRE I had dynamically supplied. However everytime I run the applet a Java security warning comes up saying "The application requires an earlier version of Java", I wanted to suppress this message but after research I tried adding 'deployment.security.mixcode=HIDE_RUN' to the deployment.properties, that did not work. I tried disabling the Next Generation Plugin, that worked to suppress the message however internet explorer was no longer using my dynamically supplied JRE for applets in IE, so that was not going to work for my purposes. My questions are:
1. Is there a reliable way(not using ssvagent) to programmatically enable and disable Java's Next Generation Plugin option? (I want to make sure it is enabled when launching third party application from the portal)
2. Is there a programmatic way to suppress the Java Security Warning "The application requires an earlier version of Java", without disabling Java's Next Generation Plugin option?
deployment.properties entries after addition of my jre entry:
Note: The reason not to use most recent version of Java is the necessity to test the third party application prior to deployment of a new Java version and since I do not control when a new version of Java is deployed and enabled to our machines, I am required to find an transparent solution. I understand the security issues by doing so, but the time between testing and acceptance of a new Java version for our application is within an acceptable timeframe. On exiting the application, I would restore the JRE settings and restore previous settings, to minimize the exposure of a potential security risk. Also any manual configurations are trying to be avoided as to maintain transparency to the user.