Hi Alan,

I am still convinced that inability to get user name is not a good reason to terminate execution (with exception or fatal error). I am afraid that this could break existing programs that perform well when user name is not known. They can be even unconscious that they work in such strange conditions.

Looking at code near I can see that there is not consistent approach. Solaris/Linux part fails with exception if current directory is not known, while Windows part is optimistic about this. Maybe the best approach is somewhere between these extreme ones.

Just an idea: what about to put diagnostic message just in system property? So it may look something like

    user.name="?: GetUserName failed, GetLastError=1115: A system shutdown is in progress."

This way we provide better diagnostics than if we report plain "unknown" and at the same time we let application ignore failure if it is not relevant for it.


By the way, getting current directory on Windows is also slippery.
In code we inform GetCurrentDirectory that our buffer is twice longer than we actually reserved.

    /* Current directory */
    {
        WCHAR buf[MAX_PATH];
        GetCurrentDirectoryW(sizeof(buf), buf);
        sprops.user_dir = _wcsdup(buf);
    }

Again, this can be not an issue since it's not easy to create directory longer than MAX_PATH.

Regards,
Dmytro


Date: Wed, 9 Feb 2011 12:50:04 +0000
From: Alan.Bateman@oracle.com
To: dmytro_sheyko@hotmail.com
CC: core-libs-dev@openjdk.java.net
Subject: Re: Some issues on identifying user.name on Windows

Dmytro Sheyko wrote:
Hi,

Maybe it makes sense to use environment variables on Linux (and Solaris) as well in order to minimize failure of "user.name" and "user.home" detection, doesn't it?
Yes, I think this makes sense. Typically USER and LOGNAME are set (we might just need to think about the sudo case).


As for Windows, many Win32 functions fail when system is shutting down, and GetUserName shouldn't be an exception. But I don't know other conditions till now.

I believe that JVM shouldn't stop working if user name can't be determined because many applications do not need to know it at all.
The counter argument is that applications that do require it could fail in unpredictable ways. I've seen a couple of cases but never Windows. Another suggestion is to emit a warning, something that might be feasible for debug/fastdebug builds (probably not product because messages coming from the runtime can cause other problems, and can confuse tests). Minimally we need something to make it easier to diagnose.

Actually system properties don't seems very reliable source for those applications that DO need user name. One can easily cheat them by setting env var USERNAME (on Windows)
or just passing -Duser.name in command line explicitly. I think this kind of application needs separate API that provides true system information and better diagnostics
in problematic cases.

As for default value for "user.name" I changed my mind. I think we shouldn't place "user.name" to system properties at all if user name cannot be determined.
(Of course, documenting this behavior well in System.getProperties() javadoc)
I don't think this is an option because it would break existing code that assumes user.name is set.

It would be easier to handle quite rare problematic cases with following code

    String username = System.getProperty("user.name", fallbackUsernameValue);

than with

    String username = System.getProperty("user.name");
    if (username.equals("?") || username.equals("unknown")) {
        username = fallbackUsernameValue;
    }
We don't document "?" or "unknown" but it would not surprise me to find code like this.

Anyway back to your original patch, what would you think about modifying it so that it throws an exception if GetUserNameW fails rather than defaulting to "unknown"? You mentioned the "Windows is shutting down" case (and you may be right on that) but I can't think of any others except period insufficient resources in which case we'll probably keel over anyway.  We can separate this from the Solaris/Linux changes as that is the most likely places where it might fail and default to "?" today.

-Alan