Some issues on identifying user.name on Windows

[Dmytro Sheyko]

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 at oracle.com
To: dmytro_sheyko at hotmail.com
CC: core-libs-dev at 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. 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20110209/a7adbe21/attachment.html>