|
Duplicate :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Name: nt126004 Date: 12/03/2002
FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
FULL OPERATING SYSTEM VERSION :
Microsoft Windows XP [Version 5.1.2600]
ADDITIONAL OPERATING SYSTEMS :
All Windows
A DESCRIPTION OF THE PROBLEM :
The Java runtime looks (as far as I can see) at the
Registrykey
"[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersio
n\Explorer\Shell Folders\Desktop]"
and strips the last directory of this value.
As this is a derived value from a Registry-key whose
purpose is *NOT* to point at the users home directory, this
behaviour is likely to fail.
We have seen some cases, where the mentioned registry entry
changed during a windows session or after a restart. So a
Java-program's behaviour depends on when the user has
started a programm (before or after the change to the
registry, which the user probably does not know about).
After all, its really difficult to track down the reason
for a java-programs malfunction, because the mentioned
registry entry is not easy to find, and the Environment-
variable "USERPROFILE" - which should be the source
of "user.home" (this is my opinion) - does not
influence "user.home" at all.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.change the above windows registry value to an other value
(e.g. "c:\MyDesktopFolder")
2.run PropertyTest.java
3.type "set USERPROFILE" inside windows cmd-line (shell)
EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected Result:
PropertyTest returns what Windows thinks is the User Home
directory, which should be the same value as "set
USERPROFILE" returns, e.g. "C:\Dokumente und Einstellungen\TestUser1".
Actual Result:
PropertyTest returns "C:", whereas "set USERPROFILE" still
returns "C:\Dokumente und Einstellungen\TestUser1" !
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
/* precondition:
alter "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shel
l Folders\Desktop" prior to running this test */
public class PropertyTest{
public static void main(String[] args) {
System.out.println(System.getProperty("user.home"));
}
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
No simple workaround for us, since it depends on how our
customer deploys our application to his employees.
Reading the Environment-variable "USERPROFILE" on
Application startup is not that simple because of other
java-bugs (Exec for batch-files...).
If a customer has a problem (most often, our Application
won't start at some time (hopefully not during a
presentation to the management ;-(, because the "user.home"
is different, and the license-information file can not be
found anymore), we can tell him to manually edit the
registry, which is so awful and unprofessional for
a "professional application plattform" like java should be
one.
(Review ID: 178403)
======================================================================
|