United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6509291 REGRESSION:Launching java using the jvm.dll no longer works without msvcr71.dll in the system path
6509291 : REGRESSION:Launching java using the jvm.dll no longer works without msvcr71.dll in the system path

Details
Type:
Bug
Submit Date:
2007-01-03
Status:
Closed
Updated Date:
2011-02-15
Project Name:
JDK
Resolved Date:
2010-10-05
Component:
install
OS:
solaris_7,windows_xp,windows
Sub-Component:
install
CPU:
x86,sparc
Priority:
P4
Resolution:
Won't Fix
Affected Versions:
6,6u14,7
Fixed Versions:

Related Reports
Duplicate:
JDK-7019193 - JDeveloper 11g fails to launch with JDK 7 b128
Relates:
JDK-6509739 - JNI/Windows: Document requirement to install msvcr71.dll alongside custom launchers

Sub Tasks

Description
J2SE Version (please include all output from java -version flag):
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

Does this problem occur on J2SE 1.4.x or 5.0.x ?  Yes / No (pick one)
No

Operating System Configuration Information (be specific):
Microsoft Windows 2000 [Version 5.00.2195]

Regression: Launching java using the jvm.dll no longer works without msvcr71.dll in the system path

This seems to be related to bug 6368613, however it does not work in build 1.6.0-b105.

Many applications deploy java and don't install it rather just use the jvm.dll to launch it.
From memory all the following applications do that Tomcat, WebLogic and JBuilder etc.

In our javapath for our launcher we have to specify the exact location to the jvm.dll (eg /bin/client/jvm.dll).
We can not specify additional paths to search for the msvcr71.dll.

On computers that don't have msvcr71.dll in their system path when java is launched they are receiving the error message that 'The dynamic linked library msvcr71.dll could not be found in the specified path' followed by the error message 'Unable to load the dll '/bin/client/jvm.dll''

This worked fine on all versions of java that we have tested over the last 5 years and only became a problem with JRE 1.6.

The msvcr71.dll is located at /bin/msvcr71.dll.

All the workarounds involve copying msvcr71.dll to somewhere already in the path, or changing the system path to point to this copy of msvcr71.dll. Neither is a possibility for us as that would involve messing with the clients computers.

Comments
EVALUATION

If the other products are using a custom launcher and trying to use the jvm.dll, they
should correctly open the msvcrXX.dll using LoadLibrary, or set the %PATH% variable correctly. 

If a customer really needs this, they can escalate.
2010-10-05 
EVALUATION

Rather than place msvcr71.dll in JAVA_HOME\bin, SAS is suggesting to place it in JAVA_HOME\bin\client.

For JNI implementers such as SAS, they could then use LoadLibraryEX(full_jvm_dll_path, NULL, LOAD_WITH_ALTERED_SEARCH_PATH ) and not run into this issue.

Is there a technical reason we can not move msvcr71.dll into JAVA_HOME\bin\client, (or place a copy or soft link?)
2009-03-16 
EVALUATION

Java SE 6 has been shipping to millions of users since 2006.  Moving or copying msvcr71.dll may potentially break existing deployments of Java.  Therefore, we 
cannot accept the suggested fix as submitted.
2009-03-16 
EVALUATION

Windows Java SE 6 applications using custom launchers must be installed with msvcr71.dll in the same directory as the launcher executable.  According to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_C_Run.2d.Time_Libraries.asp, this is the new Microsoft C runtime distribution model:

"An application should use and redistribute msvcr71.dll, and it should avoid placing a copy or using an existing copy of msvcr71.dll in the system directory. Instead, the application should keep a copy of msvcr71.dll in its application directory with the program executable. Any application built with Visual C++ .NET using the /MD switch will necessarily use msvcr71.dll."

Unfortunately there's nothing we can do in jvm.dll to work around this.

We should still update the documentation to reflect this so that customers are aware - a separate bug will be filed for that purpose.

Closing as "not a defect".
2007-01-04


Hardware and Software, Engineered to Work Together