Review request: JDK-6519127 Vista: user.home property not set correctly

[Alexey Utkin]

On 21.01.2013 20:01, Alan Bateman wrote:
> 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.
The Shell32.dll is a part of Windows kernel. It is always in memory. The 
DLL code segments are shared between process instances until load 
address conflicts (that is not the case for Java) .
The initialization of Shell32.dll data segment postponed till the first 
use. So, the reduction in the performance would be minimal.

That is about the corner cases. Java definitely changes code flow in 
fix. But it is the bug subject. Suggested solution makes Java compatible 
with the rest of Win32 applications.
In accordance with Chen's article (he is an expert!)
http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx
the registry entries got the values ones. That is a problem for any 
dynamic system. An upgrade is a kind of dynamic conversion that could 
make a problem.

> 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.
That is a corner case. In the latest versions of OS, MS is trying to 
follow "lazy" strategy in everything. Nothing is been instantiating 
before the first use. But Java needs the home folder.
So, we have the right to request the creation. That is OS solution to 
accept or decline the request.
>
> I think it's okay to leave out the comment at L529 as it might be 
> confusing when there isn't any registry code.
>
Agree. Comment at L529 will be removed.
> Otherwise I think the change is okay, definitely something for a major 
> release rather than an update release.
Thanks, Alan!
-uta