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

Alexey Utkin alexey.utkin at oracle.com
Thu Mar 7 13:21:10 UTC 2013

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 OCLOEXEC 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 ssizet. Something for another day but we would re-examine handleAppend as the file should be open for OAPPEND 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 (ioutilmd.c), probably should use 4-space indent. That's all I have. -Alan.

More information about the core-libs-dev mailing list