We distribute a java application which was developed based on 32-bit Java 1.5.0_22 through Java WebStart technology.
In difference to this quite old Java version our clients have installed a newer JRE like 32-bit 1.7.0_21. As long as everything is 32-bit every application could be started via WebStart. WebStart itself starts based on 1.7.0_21 (32-bit) and does the jar synchronisation with the server. After ensuring that the client jars are up-to-date, it starts a new process based on the desired JRE 1.5.0_22 and launches the application.
Unfortunately more and more of our customers receive Java Updates to the 64-bit platform since many customers switch over to 64-bit operating systems.
If we install a 64-bit version of Java 1.7.0_21 we are not able to launch any of our 32-bit 1.5.0_22 applications anymore. It seems that 64-bit WebStart is not able to switch over to respectively start a 32-bit 1.5 Java application.
In this case none of our applications will start. Instead of the application we receive the following StackTrace:
at com.sun.deploy.config.WinPlatform.getPlatformUserHome(Native Method)
at com.sun.deploy.config.WinPlatform.getUserHome(Unknown Source)
at com.sun.deploy.config.WinPlatform.getLocalStorageDir(Unknown Source)
at com.sun.deploy.config.Config.getLocalStorageDir(Unknown Source)
at com.sun.deploy.config.Config.getDefaultCacheDirectory(Unknown Source)
at com.sun.deploy.config.DefaultConfig.init(Unknown Source)
at com.sun.deploy.config.DefaultConfig.<init>(Unknown Source)
at com.sun.deploy.config.DefaultConfig.getDefaultConfig(Unknown Source)
at com.sun.deploy.config.Config.get(Unknown Source)
at com.sun.javaws.Main.main(Unknown Source)
We appreciate any hint on this issue - thanks!
Resolution: We still were not able to solve this issue! The only way to get out of this is to install the JRE1.5 as the x64 variant. In this case no switching from 64-bit to 32-bit is needed and everything is on track again.
But this is still strange and unexplainable :-(