-
Bug
-
Resolution: Fixed
-
P3
-
7
-
b134
-
generic
-
generic
-
Not verified
6710203: Regression: JavaWS can not launch JDK 142 app from command line
was fixed in 6u10 by adding some code to pre-load msvcr71.dll.
See src/common/windows/classes/com/sun/deploy/config/WinConfig.java
As we are upgrading the compiler used in JDK7, that code needs to
load a newer version of the library. That is fine and will be handled
as part of the compiler upgrade.
However there is an assertion in the code that this is only applicable
to 32 bit. Presumably because there was (a) no 64 bit javaws in 6u10
and (b) even when there became one in 6u12, it didn't matter because
we'd only ever shipped 64 bit JRE's compiled with the April 2005 SDK
compiler, which is essentially VS2005. So there was no possibility
of loading the old version.
But I suspect that when we upgrade the compiler in JDK 7, the
scenario might arise that the older dll needs to be pre-loaded
for the same kind of 64 bit javaws.exe test case.
I think the fix comes down to rather than bailing on the 64 bit
case, pre-loading the current dll, which is expected to be msvcr100.dll.
I'd prefer not to fix this part myself (in the compiler upgrade)
as I don't think I can test it properly. So at Thomas' suggestion
I am filing this as a bug to be picked up by the webstart team.
It can be addressed once the rest of the compiler upgrade work is in.
In that case, if we are fully on VS2010 by then, at the same time
you can strip out my code in the 32 bit path which has to figure
out the compiler the JDK was built with by looking for msvcr71.dll
as well.
was fixed in 6u10 by adding some code to pre-load msvcr71.dll.
See src/common/windows/classes/com/sun/deploy/config/WinConfig.java
As we are upgrading the compiler used in JDK7, that code needs to
load a newer version of the library. That is fine and will be handled
as part of the compiler upgrade.
However there is an assertion in the code that this is only applicable
to 32 bit. Presumably because there was (a) no 64 bit javaws in 6u10
and (b) even when there became one in 6u12, it didn't matter because
we'd only ever shipped 64 bit JRE's compiled with the April 2005 SDK
compiler, which is essentially VS2005. So there was no possibility
of loading the old version.
But I suspect that when we upgrade the compiler in JDK 7, the
scenario might arise that the older dll needs to be pre-loaded
for the same kind of 64 bit javaws.exe test case.
I think the fix comes down to rather than bailing on the 64 bit
case, pre-loading the current dll, which is expected to be msvcr100.dll.
I'd prefer not to fix this part myself (in the compiler upgrade)
as I don't think I can test it properly. So at Thomas' suggestion
I am filing this as a bug to be picked up by the webstart team.
It can be addressed once the rest of the compiler upgrade work is in.
In that case, if we are fully on VS2010 by then, at the same time
you can strip out my code in the 32 bit path which has to figure
out the compiler the JDK was built with by looking for msvcr71.dll
as well.
- relates to
-
JDK-7027508 failed when verify 6947403, java.lang.UnsatisfiedLinkError: RegOpenKey happened
- Closed