the situation I found this bug was rather complicated.

I was loading MAPI32.dll in JNI code by LoadLibrary(), and using GetProcAdress trying to call some APIs. But I found those calls break the path setting.
My JNI code looks like:

JNIEXPORT void JNICALL_Java_com_sun....nativeTest(....) {
    ....
    hlibMapi = LoadLibrary("MAPI32.dll");
    lpMapiLogon = (LPMAPILOGON) GetProcessAddress (hlibMapi, "MAPILOGON");
    ulResult = lpMapiLogon(....);
    ....
}

I made a testcase as following:
....
public static void main(String[] args) {
    File myFile = new File("tmpFile");

    myJavaCode.test() /* calls the nativeTest method listed above */

    try {
        myFile.createNewFile();
    } catch (IOException e) {
    ...
    }
}
    
In this case, the tmpFile should have been generated in the current working directory. But actually it was generated in elsewhere.
I found that windows actually redirect mapi32.dll to other dlls according to the different default mailer setting, for example, if Outlook Express was set as the default, the dll finally called would be C:\Program Files\Outlook Express\msoe.dll. and in the Outlook Express case, the tmpFile would be created to C:\Program Files\Outlook Express\ dir.
However if we directly point the dll to msoe.dll, the tmpFile would be created well to the current working directory. so I suspect that there was something wrong with JNI when calling redirected dlls on Windows.

Hope I've made the problem clear.