Issue 59009 - Clean up javaldx for Java mustang
Summary: Clean up javaldx for Java mustang
Status: ACCEPTED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: 680
Hardware: All All
: P3 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-07 08:14 UTC by Stephan Bergmann
Modified: 2013-02-07 21:56 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2005-12-07 08:14:09 UTC 
In SUN's Java mustang (aka Java 6) on Linux and Solaris, there will be no more
need to set LD_LIBRARY_PATH (also see Hamburg-internal #104381#).  Thus, the
following simplification can be made:  In javaldx, return an empty string for
SUN Java >= mustang (need to check how related JVMs like Blackdown behave, too);
in those places that call javaldx, take care not to extend LD_LIBRARY_PATH if
the string returned by javaldx is empty.
Comment 1 joachim.lingner 2006-05-18 16:56:53 UTC 
.
Comment 2 Stephan Bergmann 2008-03-13 17:22:22 UTC 
However, it appears that the java executable still re-execs itself with
LD_LIBRARY_PATH set, and if soffice is then spawned via java.lang.Runtime.exec
it inherits the LD_LIBRARY_PATH, and if soffice does not put the "safe"
javaldx-computed directories at the front of LD_LIBRARY_PATH, instantiating a
JVM in the soffice.bin process will crash due to the "unsafe" directories put on
the LD_LIBRARY_PATH by the java executable (see Sun-internal #b6670965#).