On 18/01/2013 16:40, Alexey Utkin wrote:
The main difference is that after the fix Java becomes the program
that could be certified by MS as Vista comparable.
Java would support the dynamic user profiles and follow the changes
in Windows OS policy (profiles migration).
Java would able to support long home directories (Windows API migrates
from limited-length paths, that were the FAT FS limitation, to
unlimited-length paths).
The only compatibility issues could happen on the systems that uses
Registry-based redirection by the way that was reserved for Java
property define switch -Duser.home=XXXX.
I would like repeat it again: after the fix Java becomes Vista
comparable program, that catch up changes from Windows OS management
tools.
For the special cases we have compatibility solution: Java define for
"user.home" property.
From MS point of view the User's home directory could not be used
directly for data storage. The specialized [Document], [Downloand],
and etc. sub-folders need to be used.
Often configs are stored in [.XXXX] sub-folders. That does not make MS
happy, but that is common practice for cross-platform tools. On that
field Java plays together with SSH, cygwin,
Firefox, Netbeans and all other well-known products. The behavior
could not be easily change (MS would happy to move configs into
[AppData\Local] sub-folder, but it is not a Java problem).
Regards,
-uta
It's good to get rid of the registry code, I just wonder if using the
shell API will have impact on startup performance. I also wonder about
corner-case configurations.
One thing on SHGetKnownFolderPath is that you specify KF_FLAG_CREATE and
I'm not sure if that is right because we don't want the JDK creating the
user's directory if it doesn't exist.
I think it's okay to leave out the comment at L529 as it might be
confusing when there isn't any registry code.
Otherwise I think the change is okay, definitely something for a major
release rather than an update release.
-Alan.
