Some issues on identifying user.name on Windows

Alan Bateman Alan.Bateman at oracle.com
Tue Feb 8 13:30:19 UTC 2011


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/20110208/8297e829/attachment.html>


More information about the core-libs-dev mailing list