0

At our company we have a few applications running through java applets from various outside vendors. Our problem is this: app1 can only run on JRE 1.6.05 whereas app2 needs 1.6.16. Is there a way that we can specify which applet gets which JRE instead of picking just one JRE for all applets (and hence all users)? I don't believe that we should mandate one JRE for all users since any of these vendors because even if we find a solution, one of the vendors will release a new patch at some point that will restart this entire cycle again.

3
  • 1
    Are you hosting the applets and do you can you change the APPLET / OBJECT / EMBED tag that loads them? Dec 1, 2009 at 16:59
  • We are hosting the applets.
    – Zombies
    Dec 1, 2009 at 17:14
  • 1
    Yuck. I've never had to deal with that. I've run across a couple apps that only run on 1.4.2, but all the rest seem to run on whatever the latest is, with no problems. Dec 9, 2009 at 14:37

3 Answers 3

1

This sort of dependency incompatibility is one of the things that application virtualization is great for sorting out.

Using application virtualization you can package each difficult app along with it's particular version of the JVM into one virtual 'bubble' on the machine where it won't even see that there are other virtualized apps with their own versions of JVM installed in their own walled-off bubbles.

Application virtualization is provided by systems like Microsoft's App-V (formerly Softgrid), Symantec/Altiris's Software Virtualization Solution (SVS), Citrix XenApp or VMWare ThinApp.

2
  • If you have externally-driven security requirements (policy, regulation, etc) you need to be careful with this model. Virtualization is a great way to get everything working, but the downside is that you may have security exposure to Java flaws. Dec 9, 2009 at 15:15
  • True, but equally it can massively reduce your exposure. If you have apps/sites that require specific older versions of Java, you can give that app the exact version it wants, whilst making the main system wide Java install the latest security patched version. The alternative would be to only install the version that works with your apps and never upgrade the system-wide version to anything newer than that.
    – GAThrawn
    Dec 11, 2009 at 13:47
0

You also have the added problem of widely exploited security vulnerabilities that make it a high risk to continue to run outdated java applets.

The solution is to stop using client-side Java, disallow internet access for users with admin rights, or deploy some sort of security appliance/proxy.

0

Prior to 6u10, the PlugIn JVM ran inside the browser. You can only have one JVM instance per process, so applets using different versions wasn't about to fly. Since 6u10, applets are run in a different process. With multiple external processes, version selection for applets is possible. The information is somewhere on the Sun websites...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .