Java Web Start 1.6 fails to start application without Java Consol on Vista

Question

Hi All,
I've faced with problem related to starting my application in IE 7 on Vista SP1 using Java Web Start (JRE 1.6.0_12 and 1.6.0_13). I suppose that issue appears after 11th update of JRE 1.6 since it works fine before.
There were set settings to indicate initial and maximal size of the Java heap in the JNLP file.
Application consist of 2 JAR files and they are signed with the same certificate.
When user tried to start application there is no any activity after accepting certificate. After starting application javaw.exe just disappeared from processes list without any message or error.
When I changed default setting in Java Control Panel to show Java Console, I noticed that the application began to start. But it's not a solution of the issue, since all customers cannot be required to turn on Java console.
I believe this is a bug in JRE as the application starts with Java console and doesn't without it.
When I browsed the web looking for the solution or an advice I found Release notes for 1.6.0_014 where it was said that 6u14 Java Web Start failed to launch and notifies that JARs were not signed, if an insecure Java system property was specified in a sandbox JNLP file. In spite of that 14th updated wasn't used and there was no notification I tried to start application without settings for the Java heap and it worked.
Could someone help me with advice, since the application cannot be started with default heap size settings.
Thanks in advance.
Edited by: vovanst on Jul 28, 2009 8:06 AM

Answer 1

Hi,
as the 6u15 just arrived and the above mentioned bug should've been fixed (though I was unable to verify through the release notes), the error is still in there.
We have no timestamped jars, neither ours nor the bouncy castle ones, all certs are valid, ours is self signed.
6u13 runs, 6u14/6u15 won't.
I followed the instructions here: http://bouncycastle.org/devmailarchive/msg10415.html to no avail.
The bcprov.jar is wrapped in its own jnlp and referred as extension from the "main" jnlp.
The interesting parts of the stack trace are these:
Caused by (via getCause): java.lang.SecurityException: JCE cannot authenticate the provider BC
     at javax.crypto.Cipher.getInstance(DashoA13*..)
     at javax.crypto.Cipher.getInstance(DashoA13*..)
Caused by (via getCause): java.util.jar.JarException: Cannot parse https://localhost:8443/deploy/bcprov.jar
     at javax.crypto.SunJCE_c.a(DashoA13*..)
     at javax.crypto.SunJCE_b.b(DashoA13*..)
     at javax.crypto.SunJCE_b.a(DashoA13*..)
     at javax.crypto.Cipher.getInstance(DashoA13*..)
     at javax.crypto.Cipher.getInstance(DashoA13*..)
For me it seems there's a problem with resolving the url of the bcprov.jar, which would explain the lack of a delay which normally occurs when JCE verifies the signature of the bcprov provider classes. The error pops up almost instantly.
I'm clueless what to do now. Did Sun really achieve to completely destroy JCE provider functionality in Javaws, forcing us to use an alternative implementation?
Patric