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? 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. 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) 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; } Regards, Dmytro Date: Tue, 8 Feb 2011 13:30:19 +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 Message body Dmytro Sheyko wrote: Hi, I noticed following code openjdk-7-ea-src-b127-27_jan_2011\jdk\src\windows\native\java\lang\java_props_md.c /* * User name * We try to avoid calling GetUserName as it turns out to * be surprisingly expensive on NT. It pulls in an extra * 100 K of footprint. */ { WCHAR *uname = _wgetenv(L"USERNAME"); if (uname != NULL && wcslen(uname) > 0) { sprops.user_name = _wcsdup(uname); } else { WCHAR buf[100]; int buflen = sizeof(buf); sprops.user_name = GetUserNameW(buf, &buflen) ? _wcsdup(buf) : L"unknown"; } } Dmytro - I agree this code should be fixed. On the buffer size, my guess is that it's rare to have a 50+ character username and so it probably hasn't been an issue. I think the issue of what to do when the username cannot be determined is a good question and should be re-examined. Defaulting to "?" or "unknown" is problematic as some applications need to use the value of the user.name propety in file names or as a key. We've had a few reports of problems on Linux where user.name is defaulting to "?". In the examples that I looked at it was because the 32-bit JDK was being used on a 64-bit system and the 32-bit libnss_ldap wasn't installed. Minimally we need to make these types of issues easier to diagnose, and perhaps look at the implications of having the startup fail if the username cannot be determined. In the your patch you propose to standardize on "?" if the username cannot be determined and I just wonder if there are any genuine conditions where it might fail on Windows and whether is there might be any existing code depending on "unknown" (I hope not). -Alan.