Some issues on identifying on Windows

Dmytro Sheyko dmytro_sheyko at
Fri Feb 11 09:13:12 UTC 2011

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"?: 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.


Date: Wed, 9 Feb 2011 12:50:04 +0000
From: Alan.Bateman at
To: dmytro_sheyko at
CC: core-libs-dev at
Subject: Re: Some issues on identifying on Windows


Dmytro Sheyko wrote:



Maybe it makes sense to use environment variables on Linux (and
Solaris) as well in order to minimize failure of "" 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

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 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 "" I changed my mind. I think we
shouldn't place "" to system properties at all if user name
cannot be determined.

(Of course, documenting this behavior well in System.getProperties()

I don't think this is an option because it would break existing code
that assumes is set.

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


    String username = System.getProperty("",


than with


    String username = System.getProperty("");

    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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the core-libs-dev mailing list