[Libreoffice-bugs] [Bug 50584] LibreOffice says that Java runtime JRE 1.7 on Windows is defective

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50584

Michael Stahl <mstahl at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|libreoffice-bugs at lists.free |timar74 at gmail.com
                   |desktop.org                 |
                 CC|                            |fridrich.strba at bluewin.ch,
                   |                            |mstahl at redhat.com
            Summary|LibreOffice help does not   |LibreOffice says that Java
                   |recognize Java runtime 1.7x |runtime JRE 1.7 on Windows
                   |                            |is defective

--- Comment #2 from Michael Stahl <mstahl at redhat.com> 2012-07-18 12:55:32 PDT ---
i have found out why JRE 7 does not work for some people:

LO wants to dlopen (or whatever the Win32 equivalent is) "jvm.dll",
which requires "msvcr100.dll"; the JDK contains several copies of
this library, but none in the same directory as jvm.dll
(which is inside a "client" subdirectory).

if the MSVC runtime is not installed globally in the system,
then the dlopen will fail, and the result is an error message
complaining about a "defective" Java runtime.

there are two options to work around this defect in the JRE:

1. bundle the msvcr100.dll, and install it either in "program"
   or globally in the system, so that the runtime loader finds it
2. depending on the selected JRE, set PATH variable to include
   the JRE directory in which the msvcr100.dll is located

currently it looks like bundling is the easier to implement option,
i'll paste some discussion from IRC:

<sberg> mst__, on Unix, we could fix this with javaldx (which came into being
to fix a similar problem, that by now should be fixed in the JRE -- and that
indeed took years), but on Windows...
<sberg> mst__, then maybe old JRE versions had the same bug (but used
msvcr90.dll instead) and that went unnoticed as we include msvr90.dll in the
program dir, anyway (we still do, don't we?)
<mst__> sberg, what's the problem with setting $PATH?
<sberg> mst__, set it where?
<sberg> mst__, and to what value?
<mst__> sberg, that's the question :) i have no idea how that could work,
perhaps in soffice.exe?
<sberg> mst__, but it's also needed for other processes that can spawn jvm
(like uno.exe), so it easily gets messy
<mst__> sberg, is it possible to find out in these soffice.exe etc. what JRE is
configured? and is switching JREs supposed to work without restart?
<sberg> mst__, "finding out what JRE is configured": that's what javaldx does,
and its (sort of) a mess, Jochen always did the work on that, so I'm not too
sure about the details, but it's not nice; switching JREs w/o restart is not
supposed to work
<sberg> mst__, so if we can bundle msvr100.dll and install it globally, like we
already do for mscvr90.dll, I would very much favor that as a fix

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.