Re: Request for code review 6512101: Incorrect encoding in NetworkInterface.getDisplayName()
Frank, Excellent! Thank you for doing it. -Dmitry On 2012-12-10 12:00, Frank Ding wrote: Hi Dmitry, I updated wording accordingly @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.03. It is now changed to Cannot get multibyte char for interface display name. What about that? Best regards, Frank On 12/10/2012 3:43 PM, Dmitry Samersoff wrote: Frank, Looks good for me. May be Can't get WIDE string should be changed to something more verbose. -Dmitry On 2012-12-10 11:40, Frank Ding wrote: Hi Dmitry and Chris, Could you please review the second revision again? Thanks and Best regards, Frank On 11/29/2012 1:08 PM, Frank Ding wrote: Hi Dmitry and Chris, Thanks for your comments. With your comments incorporated, I've prepared v2 @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.02/. Could you please review it again? Best regards, Frank On 11/14/2012 12:12 AM, Chris Hegarty wrote: On 11/11/2012 07:03 PM, Dmitry Samersoff wrote: Frank, Changes look good for me. I admit that I am not an expert in this area, but given the information you provided, and I guess you verified this in your environment, the conversion would appear reasonable. But it might be better to fall back to original behavior if MultiByteToWideChar return error, rather than abort. I agree with Dmitry, fall back would be preferable. Can you make the changes and post an updated webrev. -Chris. -Dmitry On 2012-11-07 13:08, Frank Ding wrote: Hi guys, Could you please take a look at patch below aimed to resolve existing bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512101 ? http://cr.openjdk.java.net/~dingxmin/6512101/webrev.01/ I happen to have a Chinese Win 7 environment. buggy.png is current output of test case described in bug system whereas fixed.png is the output after the my patch is applied. http://cr.openjdk.java.net/~dingxmin/6512101/buggy.png http://cr.openjdk.java.net/~dingxmin/6512101/fixed.png The patch simply converts to wide chars encoded in CP_OEMCP by calling MultiByteToWideChar. We have confirmed a guy from Microsoft who said that BEGIN QUOTE I'm not sure how common it is to call the Java code that results in calling the GetIfTable API but I would guess it does not happen that often. Additionally, if it's rare that the adapter contains the accented characters, it would definitely be quite easy to miss in testing. I have not found any documentation about the encoding of the bDescr string unfortunately. I did, however, debug through the API and located the place where it is generated. It is getting converted from a UTF-16 string to a single-byte string using a conversion like this: WideCharToMultiByte( CP_OEMCP, WC_NO_BEST_FIT_CHARS, source string, -1, IfRow-bDescr, size, NULL, NULL); I have checked the source for Windows Vista, 2008, Windows 7, and Windows 2008 R2. It is using CP_OEMCP in all of them. So using the reverse conversion in your code using CP_OEMCP should be safe. Alternatively, you can use the GetIfTable2 function (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365945^(v=vs.85).aspx ) which returns the same information in the original UTF-16 encoding. END QUOTE The link below may be helpful to the second param of WideCharToMultiByte. http://blogs.msdn.com/b/oldnewthing/archive/2012/05/04/10300670.aspx You comments are appreciated. Best regards, Frank -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer
Re: Request for code review 6512101: Incorrect encoding in NetworkInterface.getDisplayName()
Hi Dmitry, I updated wording accordingly @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.03. It is now changed to Cannot get multibyte char for interface display name. What about that? Best regards, Frank On 12/10/2012 3:43 PM, Dmitry Samersoff wrote: Frank, Looks good for me. May be Can't get WIDE string should be changed to something more verbose. -Dmitry On 2012-12-10 11:40, Frank Ding wrote: Hi Dmitry and Chris, Could you please review the second revision again? Thanks and Best regards, Frank On 11/29/2012 1:08 PM, Frank Ding wrote: Hi Dmitry and Chris, Thanks for your comments. With your comments incorporated, I've prepared v2 @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.02/. Could you please review it again? Best regards, Frank On 11/14/2012 12:12 AM, Chris Hegarty wrote: On 11/11/2012 07:03 PM, Dmitry Samersoff wrote: Frank, Changes look good for me. I admit that I am not an expert in this area, but given the information you provided, and I guess you verified this in your environment, the conversion would appear reasonable. But it might be better to fall back to original behavior if MultiByteToWideChar return error, rather than abort. I agree with Dmitry, fall back would be preferable. Can you make the changes and post an updated webrev. -Chris. -Dmitry On 2012-11-07 13:08, Frank Ding wrote: Hi guys, Could you please take a look at patch below aimed to resolve existing bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512101 ? http://cr.openjdk.java.net/~dingxmin/6512101/webrev.01/ I happen to have a Chinese Win 7 environment. buggy.png is current output of test case described in bug system whereas fixed.png is the output after the my patch is applied. http://cr.openjdk.java.net/~dingxmin/6512101/buggy.png http://cr.openjdk.java.net/~dingxmin/6512101/fixed.png The patch simply converts to wide chars encoded in CP_OEMCP by calling MultiByteToWideChar. We have confirmed a guy from Microsoft who said that BEGIN QUOTE I'm not sure how common it is to call the Java code that results in calling the GetIfTable API but I would guess it does not happen that often. Additionally, if it's rare that the adapter contains the accented characters, it would definitely be quite easy to miss in testing. I have not found any documentation about the encoding of the bDescr string unfortunately. I did, however, debug through the API and located the place where it is generated. It is getting converted from a UTF-16 string to a single-byte string using a conversion like this: WideCharToMultiByte( CP_OEMCP, WC_NO_BEST_FIT_CHARS, source string, -1, IfRow-bDescr, size, NULL, NULL); I have checked the source for Windows Vista, 2008, Windows 7, and Windows 2008 R2. It is using CP_OEMCP in all of them. So using the reverse conversion in your code using CP_OEMCP should be safe. Alternatively, you can use the GetIfTable2 function (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365945^(v=vs.85).aspx ) which returns the same information in the original UTF-16 encoding. END QUOTE The link below may be helpful to the second param of WideCharToMultiByte. http://blogs.msdn.com/b/oldnewthing/archive/2012/05/04/10300670.aspx You comments are appreciated. Best regards, Frank
Re: Request for code review 6512101: Incorrect encoding in NetworkInterface.getDisplayName()
On 10/12/2012 08:01, Dmitry Samersoff wrote: Frank, Excellent! Thank you for doing it. Ditto, thanks Frank. I assume Sean or Neil will push this for you? Otherwise, just let me know and I can do it. -Chris. -Dmitry On 2012-12-10 12:00, Frank Ding wrote: Hi Dmitry, I updated wording accordingly @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.03. It is now changed to Cannot get multibyte char for interface display name. What about that? Best regards, Frank On 12/10/2012 3:43 PM, Dmitry Samersoff wrote: Frank, Looks good for me. May be Can't get WIDE string should be changed to something more verbose. -Dmitry On 2012-12-10 11:40, Frank Ding wrote: Hi Dmitry and Chris, Could you please review the second revision again? Thanks and Best regards, Frank On 11/29/2012 1:08 PM, Frank Ding wrote: Hi Dmitry and Chris, Thanks for your comments. With your comments incorporated, I've prepared v2 @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.02/. Could you please review it again? Best regards, Frank On 11/14/2012 12:12 AM, Chris Hegarty wrote: On 11/11/2012 07:03 PM, Dmitry Samersoff wrote: Frank, Changes look good for me. I admit that I am not an expert in this area, but given the information you provided, and I guess you verified this in your environment, the conversion would appear reasonable. But it might be better to fall back to original behavior if MultiByteToWideChar return error, rather than abort. I agree with Dmitry, fall back would be preferable. Can you make the changes and post an updated webrev. -Chris. -Dmitry On 2012-11-07 13:08, Frank Ding wrote: Hi guys, Could you please take a look at patch below aimed to resolve existing bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512101 ? http://cr.openjdk.java.net/~dingxmin/6512101/webrev.01/ I happen to have a Chinese Win 7 environment. buggy.png is current output of test case described in bug system whereas fixed.png is the output after the my patch is applied. http://cr.openjdk.java.net/~dingxmin/6512101/buggy.png http://cr.openjdk.java.net/~dingxmin/6512101/fixed.png The patch simply converts to wide chars encoded in CP_OEMCP by calling MultiByteToWideChar. We have confirmed a guy from Microsoft who said that BEGIN QUOTE I'm not sure how common it is to call the Java code that results in calling the GetIfTable API but I would guess it does not happen that often. Additionally, if it's rare that the adapter contains the accented characters, it would definitely be quite easy to miss in testing. I have not found any documentation about the encoding of the bDescr string unfortunately. I did, however, debug through the API and located the place where it is generated. It is getting converted from a UTF-16 string to a single-byte string using a conversion like this: WideCharToMultiByte( CP_OEMCP, WC_NO_BEST_FIT_CHARS, source string, -1, IfRow-bDescr, size, NULL, NULL); I have checked the source for Windows Vista, 2008, Windows 7, and Windows 2008 R2. It is using CP_OEMCP in all of them. So using the reverse conversion in your code using CP_OEMCP should be safe. Alternatively, you can use the GetIfTable2 function (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365945^(v=vs.85).aspx ) which returns the same information in the original UTF-16 encoding. END QUOTE The link below may be helpful to the second param of WideCharToMultiByte. http://blogs.msdn.com/b/oldnewthing/archive/2012/05/04/10300670.aspx You comments are appreciated. Best regards, Frank
hg: jdk8/tl/langtools: 8004094: Javac compiler error - synthetic method accessor generated with duplicate name
Changeset: c78acf6c2f3e Author:mcimadamore Date: 2012-12-10 12:10 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c78acf6c2f3e 8004094: Javac compiler error - synthetic method accessor generated with duplicate name Summary: method clash check logic should skip methods marked with ACC_SYNTHETIC Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/8004094/B.java + test/tools/javac/generics/8004094/T8004094.java
Code review: 8003948 (jdk8)
Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8003948/webrev.1/ We need to filter out extraneous authentication headers when doing ntlm authentication with MS web servers and proxies. Thanks Michael
Re: Code review: 8003948 (jdk8)
Looks fine. -Max On 12/10/2012 10:30 PM, Michael McMahon wrote: Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8003948/webrev.1/ We need to filter out extraneous authentication headers when doing ntlm authentication with MS web servers and proxies. Thanks Michael
Re: Code review: 8003948 (jdk8)
On 10/12/2012 14:34, Weijun Wang wrote: Looks fine. +1 -Chris -Max On 12/10/2012 10:30 PM, Michael McMahon wrote: Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8003948/webrev.1/ We need to filter out extraneous authentication headers when doing ntlm authentication with MS web servers and proxies. Thanks Michael
Re: Code review: 8003948 (jdk8)
Thanks! On 10/12/12 14:50, Chris Hegarty wrote: On 10/12/2012 14:34, Weijun Wang wrote: Looks fine. +1 -Chris -Max On 12/10/2012 10:30 PM, Michael McMahon wrote: Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8003948/webrev.1/ We need to filter out extraneous authentication headers when doing ntlm authentication with MS web servers and proxies. Thanks Michael
Re: Code review: 8003948 (jdk8)
Michael,
150 It might be better to use regionMatches here
162 Is it intentional to always don't copy keys[0]/value[0] ?
Actually I would prefer to have this code better readable,
something like -
157 if ( ! condition ){
keys[j]=keys[j];
value[j]=value[j];
++j
}
-Dmitry
On 2012-12-10 18:30, Michael McMahon wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8003948/webrev.1/
We need to filter out extraneous authentication headers when doing
ntlm authentication with MS web servers and proxies.
Thanks
Michael
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
hg: jdk8/tl/jdk: 8003948: NTLM/Negotiate authentication problem
Changeset: fda2b2b5b98b Author:michaelm Date: 2012-12-10 14:56 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fda2b2b5b98b 8003948: NTLM/Negotiate authentication problem Reviewed-by: chegar, weijun ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/MessageHeaderTest.java
RFR 8004675: Inet6Address.getHostAddress should use string scope identifier where available
Inet6Address.getHostAddress() is specified to return the IP address string in textual presentation, followed by a '%' character and the scope identifier. This scope identifier can be either a numeric value or a string, depending on how the instance was created (if it was created with a scoped interface). This change proposes to remove the boolean field, 'scope_ifname_set', since it is not always correctly set when the instance contains a valid scoped interface. For example, when iterating over the NetworkInterface's on the system. 'scope_ifname_set' was never accessed from native code, so it can simply be removed. http://cr.openjdk.java.net/~chegar/8004675/webrev.00/webrev/ -Chris.
Re: Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format
Shouldn't 'cal.set(1970, 0, 1, 0, 0, 0)' be inside the for loop? The test can simply throw Exception, rather can catching. Otherwise, looks fine to me. -Crhis. On 06/12/2012 21:19, Rob McKenna wrote: Hi folks, According to HttpCookie.java: There are 3 http cookie specifications: Netscape draft RFC 2109 -/http://www.ietf.org/rfc/rfc2109.txt/ RFC 2965 -/http://www.ietf.org/rfc/rfc2965.txt/ HttpCookie class can accept all these 3 forms of syntax. According to http://www.ietf.org/rfc/rfc2109.txt section 10.1.2: Netscape's original proposal defined an Expires header that took a date value in a fixed-length variant format in place of Max-Age: Wdy, DD-Mon-YY HH:MM:SS GMT Thats in the Historical section provided to allow for compatibility with Netscape's implementation, which we also support: (as per http://docs.oracle.com/javase/6/docs/api/java/net/HttpCookie.html ) While we don't support the rfc explicitly, this change follows the format specified in section 5.1.1 of rfc 6265: 3. If the year-value is greater than or equal to 70 and less than or equal to 99, increment the year-value by 1900. 4. If the year-value is greater than or equal to 0 and less than or equal to 69, increment the year-value by 2000. 1. NOTE: Some existing user agents interpret two-digit years differently. The webrev is at: http://cr.openjdk.java.net/~robm/8000525/webrev.01/ http://cr.openjdk.java.net/%7Erobm/8000525/webrev.01/ Note: The addition of setLenient(false) has required changes to two existing testcases. -Rob
reviews for 7200720 and 8003948 [7u-dev]
Could I get the following webrevs reviewed please? They are identical changes (except for one small change suggested by Dmitry) to what was done in 8 for the same issues http://cr.openjdk.java.net/~michaelm/7200720.7u-dev/webrev.1/ http://cr.openjdk.java.net/~michaelm/8003948.7u-dev/webrev.1/ Thanks Michael
Re: RFR 8004675: Inet6Address.getHostAddress should use string scope identifier where available
Looks good to me. Not related to this bug, but do we need scope_id_set then? From what I infer, scope_id_set is being set in native code, only when scope_id is not 0, and so a check with scope_id == 0 can serve the purpose of scope_id_set too. Thanks, Kurchi On 10.12.2012 08:01, Chris Hegarty wrote: Inet6Address.getHostAddress() is specified to return the IP address string in textual presentation, followed by a '%' character and the scope identifier. This scope identifier can be either a numeric value or a string, depending on how the instance was created (if it was created with a scoped interface). This change proposes to remove the boolean field, 'scope_ifname_set', since it is not always correctly set when the instance contains a valid scoped interface. For example, when iterating over the NetworkInterface's on the system. 'scope_ifname_set' was never accessed from native code, so it can simply be removed. http://cr.openjdk.java.net/~chegar/8004675/webrev.00/webrev/ -Chris. -- -Kurchi
Re: reviews for 7200720 and 8003948 [7u-dev]
Michael, On 2012-12-10 23:35, Michael McMahon wrote: Could I get the following webrevs reviewed please? They are identical changes (except for one small change suggested by Dmitry) to what was done in 8 for the same issues http://cr.openjdk.java.net/~michaelm/7200720.7u-dev/webrev.1/ I see a comment // MMM 7200720 ?? at ll: 202 of NTLMAuthentication.java - Does it make sense to change it to something more verbose? Otherwise looks good for me. http://cr.openjdk.java.net/~michaelm/8003948.7u-dev/webrev.1/ Looks good for me. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer
Re: RFR 8004675: Inet6Address.getHostAddress should use string scope identifier where available
Chris, Looks good for me. PS: Inet6Address.java: It's not necessary to remove explicit initializations - compiler do it perfectly for you. -Dmitry On 2012-12-10 20:01, Chris Hegarty wrote: Inet6Address.getHostAddress() is specified to return the IP address string in textual presentation, followed by a '%' character and the scope identifier. This scope identifier can be either a numeric value or a string, depending on how the instance was created (if it was created with a scoped interface). This change proposes to remove the boolean field, 'scope_ifname_set', since it is not always correctly set when the instance contains a valid scoped interface. For example, when iterating over the NetworkInterface's on the system. 'scope_ifname_set' was never accessed from native code, so it can simply be removed. http://cr.openjdk.java.net/~chegar/8004675/webrev.00/webrev/ -Chris. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer
hg: jdk8/tl/jdk: 4819681: Typo in http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html
Changeset: cac1bfaceaaa Author:mchung Date: 2012-12-10 15:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cac1bfaceaaa 4819681: Typo in http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html Summary: Simple capitalization typo in LogManager() description Reviewed-by: darcy, mchung ! src/share/classes/java/util/logging/LogManager.java
Infinite Loop in KeepAliveStream
Hi sun/net/www maintainers,
Here at Google we have observed an infinite loop
in jdk/src/share/classes/sun/net/www/http/KeepAliveStream.java
85: if (nskip = available()) {
86: long n = 0;
87: while (n nskip) {
88: nskip = nskip - n;
89: n = skip(nskip);
90: }
If this stream is asynchronously closed (or perhaps, read, or skipped),
then skip will always return 0 (see MeteredStream)
public synchronized long skip(long n) throws IOException {
// REMIND: what does skip do on EOF
if (closed) {
return 0;
}
and you can clearly see an infinite loop.
Unfortunately, we are too clueless about this code to be able to reproduce
this infloop at will, but we are guessing you may be able to.
Here's an infloop stack trace snippet (line numbers from openjdk6 sources)
sun.net.www.http.KeepAliveStream.close(KeepAliveStream.java:93)
java.io.FilterInputStream.close(FilterInputStream.java:172)
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.close(HttpURLConnection.java:2625)
org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.close(Unknown
Source)
org.apache.xerces.impl.io.UTF8Reader.close(Unknown Source)
org.apache.xerces.impl.XMLEntityManager.closeReaders(Unknown Source)
org.apache.xerces.parsers.XML11Configuration.cleanup(Unknown Source)
org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
Here's a possible patch that seems to make the code more correct in the
presence of asynchronous close, although guaranteeing completely correct
synchronization here seems difficult.
@@ -83,10 +83,8 @@
if (expected count) {
long nskip = (long) (expected - count);
if (nskip = available()) {
-long n = 0;
-while (n nskip) {
-nskip = nskip - n;
-n = skip(nskip);
+while (nskip 0 nskip = available()) {
+nskip -= skip(nskip);
}
} else if (expected =
KeepAliveStreamCleaner.MAX_DATA_REMAINING !hurried) {
//put this KeepAliveStream on the queue so that the
data remaining
It's very likely you can come up with a better patch.
see also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4392195
Re: Request for code review 6512101: Incorrect encoding in NetworkInterface.getDisplayName()
Hi All, Thank you all. I will have Jonathan help to commit. Best regards, Frank On 12/10/2012 6:12 PM, Chris Hegarty wrote: On 10/12/2012 08:01, Dmitry Samersoff wrote: Frank, Excellent! Thank you for doing it. Ditto, thanks Frank. I assume Sean or Neil will push this for you? Otherwise, just let me know and I can do it. -Chris. -Dmitry On 2012-12-10 12:00, Frank Ding wrote: Hi Dmitry, I updated wording accordingly @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.03. It is now changed to Cannot get multibyte char for interface display name. What about that? Best regards, Frank On 12/10/2012 3:43 PM, Dmitry Samersoff wrote: Frank, Looks good for me. May be Can't get WIDE string should be changed to something more verbose. -Dmitry On 2012-12-10 11:40, Frank Ding wrote: Hi Dmitry and Chris, Could you please review the second revision again? Thanks and Best regards, Frank On 11/29/2012 1:08 PM, Frank Ding wrote: Hi Dmitry and Chris, Thanks for your comments. With your comments incorporated, I've prepared v2 @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.02/. Could you please review it again? Best regards, Frank On 11/14/2012 12:12 AM, Chris Hegarty wrote: On 11/11/2012 07:03 PM, Dmitry Samersoff wrote: Frank, Changes look good for me. I admit that I am not an expert in this area, but given the information you provided, and I guess you verified this in your environment, the conversion would appear reasonable. But it might be better to fall back to original behavior if MultiByteToWideChar return error, rather than abort. I agree with Dmitry, fall back would be preferable. Can you make the changes and post an updated webrev. -Chris. -Dmitry On 2012-11-07 13:08, Frank Ding wrote: Hi guys, Could you please take a look at patch below aimed to resolve existing bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512101 ? http://cr.openjdk.java.net/~dingxmin/6512101/webrev.01/ I happen to have a Chinese Win 7 environment. buggy.png is current output of test case described in bug system whereas fixed.png is the output after the my patch is applied. http://cr.openjdk.java.net/~dingxmin/6512101/buggy.png http://cr.openjdk.java.net/~dingxmin/6512101/fixed.png The patch simply converts to wide chars encoded in CP_OEMCP by calling MultiByteToWideChar. We have confirmed a guy from Microsoft who said that BEGIN QUOTE I'm not sure how common it is to call the Java code that results in calling the GetIfTable API but I would guess it does not happen that often. Additionally, if it's rare that the adapter contains the accented characters, it would definitely be quite easy to miss in testing. I have not found any documentation about the encoding of the bDescr string unfortunately. I did, however, debug through the API and located the place where it is generated. It is getting converted from a UTF-16 string to a single-byte string using a conversion like this: WideCharToMultiByte( CP_OEMCP, WC_NO_BEST_FIT_CHARS, source string, -1, IfRow-bDescr, size, NULL, NULL); I have checked the source for Windows Vista, 2008, Windows 7, and Windows 2008 R2. It is using CP_OEMCP in all of them. So using the reverse conversion in your code using CP_OEMCP should be safe. Alternatively, you can use the GetIfTable2 function (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365945^(v=vs.85).aspx ) which returns the same information in the original UTF-16 encoding. END QUOTE The link below may be helpful to the second param of WideCharToMultiByte. http://blogs.msdn.com/b/oldnewthing/archive/2012/05/04/10300670.aspx You comments are appreciated. Best regards, Frank
hg: jdk8/tl/jdk: 6512101: Incorrect encoding in NetworkInterface.getDisplayName()
Changeset: 883feced1cdd Author:dingxmin Date: 2012-12-11 10:42 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/883feced1cdd 6512101: Incorrect encoding in NetworkInterface.getDisplayName() Reviewed-by: chegar, dsamersoff ! src/windows/native/java/net/NetworkInterface.c
Re: Request for code review 6512101: Incorrect encoding in NetworkInterface.getDisplayName()
Hi Frank, Patch pushed @ http://hg.openjdk.java.net/jdk8/tl/jdk/rev/883feced1cdd Best regards! - Jonathan On 12/11/2012 09:49 AM, Frank Ding wrote: Hi All, Thank you all. I will have Jonathan help to commit. Best regards, Frank On 12/10/2012 6:12 PM, Chris Hegarty wrote: On 10/12/2012 08:01, Dmitry Samersoff wrote: Frank, Excellent! Thank you for doing it. Ditto, thanks Frank. I assume Sean or Neil will push this for you? Otherwise, just let me know and I can do it. -Chris. -Dmitry On 2012-12-10 12:00, Frank Ding wrote: Hi Dmitry, I updated wording accordingly @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.03. It is now changed to Cannot get multibyte char for interface display name. What about that? Best regards, Frank On 12/10/2012 3:43 PM, Dmitry Samersoff wrote: Frank, Looks good for me. May be Can't get WIDE string should be changed to something more verbose. -Dmitry On 2012-12-10 11:40, Frank Ding wrote: Hi Dmitry and Chris, Could you please review the second revision again? Thanks and Best regards, Frank On 11/29/2012 1:08 PM, Frank Ding wrote: Hi Dmitry and Chris, Thanks for your comments. With your comments incorporated, I've prepared v2 @ http://cr.openjdk.java.net/~dingxmin/6512101/webrev.02/. Could you please review it again? Best regards, Frank On 11/14/2012 12:12 AM, Chris Hegarty wrote: On 11/11/2012 07:03 PM, Dmitry Samersoff wrote: Frank, Changes look good for me. I admit that I am not an expert in this area, but given the information you provided, and I guess you verified this in your environment, the conversion would appear reasonable. But it might be better to fall back to original behavior if MultiByteToWideChar return error, rather than abort. I agree with Dmitry, fall back would be preferable. Can you make the changes and post an updated webrev. -Chris. -Dmitry On 2012-11-07 13:08, Frank Ding wrote: Hi guys, Could you please take a look at patch below aimed to resolve existing bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512101 ? http://cr.openjdk.java.net/~dingxmin/6512101/webrev.01/ I happen to have a Chinese Win 7 environment. buggy.png is current output of test case described in bug system whereas fixed.png is the output after the my patch is applied. http://cr.openjdk.java.net/~dingxmin/6512101/buggy.png http://cr.openjdk.java.net/~dingxmin/6512101/fixed.png The patch simply converts to wide chars encoded in CP_OEMCP by calling MultiByteToWideChar. We have confirmed a guy from Microsoft who said that BEGIN QUOTE I'm not sure how common it is to call the Java code that results in calling the GetIfTable API but I would guess it does not happen that often. Additionally, if it's rare that the adapter contains the accented characters, it would definitely be quite easy to miss in testing. I have not found any documentation about the encoding of the bDescr string unfortunately. I did, however, debug through the API and located the place where it is generated. It is getting converted from a UTF-16 string to a single-byte string using a conversion like this: WideCharToMultiByte( CP_OEMCP, WC_NO_BEST_FIT_CHARS, source string, -1, IfRow-bDescr, size, NULL, NULL); I have checked the source for Windows Vista, 2008, Windows 7, and Windows 2008 R2. It is using CP_OEMCP in all of them. So using the reverse conversion in your code using CP_OEMCP should be safe. Alternatively, you can use the GetIfTable2 function (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365945^(v=vs.85).aspx ) which returns the same information in the original UTF-16 encoding. END QUOTE The link below may be helpful to the second param of WideCharToMultiByte. http://blogs.msdn.com/b/oldnewthing/archive/2012/05/04/10300670.aspx You comments are appreciated. Best regards, Frank
hg: jdk8/tl/jdk: 8004488: wrong permissions checked in krb5
Changeset: d206e52bf8a6 Author:weijun Date: 2012-12-11 13:14 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d206e52bf8a6 8004488: wrong permissions checked in krb5 Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + test/sun/security/krb5/auto/KeyPermissions.java ! test/sun/security/krb5/auto/KeyTabCompat.java
