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):
 customer  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.
Posted Date : 2007-01-03 18:53:29.0

N/A

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".
Posted Date : 2007-01-04 18:49:29.0

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?)
Posted Date : 2009-03-16 21:03:16.0

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.
Posted Date : 2009-03-16 22:29:31.0

The problem will be solved if you stop using the /MD switch.

Why doesn't the JRE redistribute msvcr71.dll, per MS's suggestion?

jbisotti: It does. This only happens if you are using a custom launcher, i.e. not using java/w.exe

I think this is _really_ serious. It makes open source development of Java launcher applications impossible, as the .dll file can not be freely redistributed. (And it probably violates a lot of licenses too)
You may say it's not a bug, but I really think that's very ignorant, as it decreases the number of programmers that can use the jvm.dll to launch their Java apps to the ones that also have a license for Visual Studio...

For a discussion of this problem and solutions:

  http://www.duckware.com/tech/java6msvcr71.html

An evaluation of "Unfortunately there's nothing we can do in jvm.dll to work around this".  Of course there is.  Follow daniel_hagg and don't use /MD.  Plus other solutions are possible.  We would like a solution, not excuses.

kieron.wilkinson: It only happens with custom launchers and not java/w.exe because Sun's does not follow their own advice in this report.

The evaluation points to the "new Microsoft new C runtime distribution model" and then Sun doesn't follow it for their own java/w.exe.  Interesting.

Wow, this is terrible. Nuff said.

"and then Sun doesn't follow it for their own java/w.exe"

We should fill another bug to prevent SUN from polluting Windows with their executables, this is bad policy to do that, SUN should read MSDN not only to discard real bugs...

Um, no ... this is wrong.

You should not make random changes to the JVM invocation API between versions. It is bad enough that the disk location of the DLL changes between versions, but adding fixed dependencies on DLLs not guaranteed to be in the PATH is nuts.

Copying msvcr71.dll into the application directory (or the Windows directories in the PATH), modifying the PATH, , or programmatically pre-loading any version-specific random dependencies - these are all quite ugly hacks.

I can understand how the Java developers at Sun missed this problem, as there is a very high probability that some other application (not following best-practices on Windows) as already copied msvcr71.dll into Windows\System32 and is then in the PATH. This is still a mistake.

The solution is simple - statically link the C runtime into JVM.DLL. There just is not a good reason to use the C runtime in a DLL. (There was a very good reason back in the Win16 days ... but those days are long gone.) 

BTW, this is the same problem and solution for distributing COM components. Nothing new here in either the problem or the solution.

Is anybody from Sun listening to this? I'm getting complains from my customers. There are too many of them to redistribute my the .dll to.

On the one hand, breaking backwards compatibility in this way is annoying. On the other hand, Visual Studio 2005 and up push hard towards this distribution model. msvcrt80.dll and msvcrt90.dll are not copied into c:\windows\system32 as was done for Visual Studio 2003 and msvcrt71.dll.

In short: as annoying as this break was, Sun is actually right about this one. They will be forced to upgrade to newer versions of Visual Studio in the near future and static linking isn't really an option because they've got over 80 programs linking to msvcrt. The size impact would be huge.

I recommend everyone bundles "shared assemblies" with their application installers as described here: http://cowwoc.blogspot.com/2008/09/fixing-visual-studio-run-time-error.html