Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

[Alexey Utkin]

Can I say two word about the file
http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html
and function
      getLastErrorString(char *buf, size_t len)

Here is the documentation for [FormatMessage]:
http://msdn.microsoft.com/en-gb/library/windows/desktop/ms679351%28v=vs.85%29.aspx
if you are using ASCII version of FormatMessage that is a good idea to  
have the direct reference to [FormatMessageA], not define.

The second word is about the third world countries: Russia and China.
Windows OS has localized version. The error messages on that systems 
would contains only [?] in the worst case.

===========================
dwLanguageId [in]
     The language identifier for the requested message. This parameter 
is ignored if dwFlags includes FORMAT_MESSAGE_FROM_STRING.
     If you pass a specific LANGID in this parameter, FormatMessage will 
return a message for that LANGID only. If the function cannot find a 
message for that LANGID, it sets Last-Error to 
ERROR_RESOURCE_LANG_NOT_FOUND.
!!!!------------>If you pass in zero, FormatMessage looks for a message 
for LANGIDs in the following order:

         Language neutral
         Thread LANGID, based on the thread's locale value
         User default LANGID, based on the user's default locale value
         System default LANGID, based on the system default locale value
         US English <-------------!!!!

     If FormatMessage does not locate a message for any of the preceding 
LANGIDs, it returns any language message string that is present. If that 
fails, it returns ERROR_RESOURCE_LANG_NOT_FOUND.
===========================


On 07.03.2013 16:40, Alan Bateman wrote:
> On 05/03/2013 18:39, Dan Xu wrote:
>> Hi All,
>>
>> Thanks for your good suggestions. I have updated this fix and put the 
>> new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/. 
>> Please help review it. Thanks!
>>
>> -Dan
>>
> I've looked at the latest webrev and it looks quite good. There are 
> several other things that should be done, like the O_CLOEXEC topic 
> that we discussed here, but they can be done later. The main thing is 
> that we've removed the dependency on the JVM_* functions and so 
> finally being the interruptible I/O story to to end.
>
> For naming then I probably should chosen something other than handle* 
> for the *nix code but I guess what you have is okay.
>
> A few comments on the *nix handleOpen:
>
> - it doesn't look like "flag" is needed as you can pass oflag to open64.
>
> - it looks like close could set errno. At least for the EISDIR case 
> you probably should set this after the close.
>
> - I assume fstat64 should use RESTARTABLE.
>
> A small comment on handleRead/handleWrite is that the return from 
> read/write is normally ssize_t.
>
> Something for another day but we would re-examine handleAppend as the 
> file should be open for O_APPEND already.
>
> Minor nit in handleAvailable is that the last if-then-else is missing 
> braces around the return 0.
>
> Minor nit in the RESTARTABLE macro (io_util_md.c), probably should use 
> 4-space indent.
>
> That's all I have.
>
> -Alan.
>
>
>