Review request: JDK-6519127 Vista: user.home property not set correctly
Anthony Petrov
anthony.petrov at oracle.com
Tue Jan 22 12:13:33 UTC 2013
Well, I think this might be a good idea in order to preserve the
performance of the former implementation. I'd suggest to introduce a
boolean system property that, when specified, would omit these flags
though, so that if someone happens to rely on this behavior, they could
get it back by specifying the system property. And I actually doubt we
would ever have to advertise this system property in real life, but it's
good to feel safe anyway. At least that is what we would do in Client code.
However, I'll leave it up to Alan to decide if this is a good solution
for Core-libs.
--
best regards,
Anthony
On 1/22/2013 15:52, Alexey Utkin wrote:
>
> Ok. Alan and Anthony,
> would you like to be faster and follow optimistic strategy, that is
> described here:
> http://blogs.msdn.com/b/oldnewthing/archive/2011/01/05/10111777.aspx
>
> That do you thing about |CSIDL_FLAG_DONT_VERIFY/||KF_FLAG_DONT_VERIFY
> flags for the |fix?
>
> Regards,
> -uta
>
> On 22.01.2013 15:14, Anthony Petrov wrote:
>> On 1/22/2013 13:48, Alexey Utkin wrote:
>>>> 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 agree with Alan. Java shouldn't forcibly create the user directory
>> if it doesn't exist yet. I suggest to pass 0 (zero) as the dwFlags
>> argument to ::SHGetKnownFolderPath(). The same applies to a call to
>> the ::SHGetFolderPathW(). getHomeFromShell32() may return NULL, so let
>> it do so if no user directory exists.
>>
>> --
>> best regards,
>> Anthony
>>
>>
>
More information about the core-libs-dev
mailing list