Integrated: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale
On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote: > I got garbled exception message as following when I run `livenmethods` CLHSDB > command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???W > > My Windows laptop is set Japanese Locale, garbled message was written in > Japanese. > saproc.dll would throw exception via > [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) > JNI function, but it accepts UTF-8 encoded message. However > [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) > Windows API might not return UTF-8 encoded string on Japanese locale. > > java.dll (libjava,so) provides good functions to resolve this issue. We can > convert localized (non ascii) chars to UTF-8 string. I use them in this PR > and remove `FormatMessage()` call from sadis.c. > And also I remove `-D_MBCS` from compiler option because [MBCS has been > already > deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) > - it does not seem to add to any other executables. This pull request has now been integrated. Changeset: 67c22114 Author:Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/67c22114 Stats: 49 lines in 2 files changed: 4 ins; 37 del; 8 mod 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale Reviewed-by: erikj, cjplummer, iklam - PR: https://git.openjdk.java.net/jdk/pull/1928
Re: [jdk16] RFR: JDK-8258657: Doc build is broken by use of new language features
On Tue, 5 Jan 2021 22:51:29 GMT, Erik Joelsson wrote: > This patch changes how the docs-reference make target behaves to better > support the requirements for it. This target is used to generate javadocs in > a more stable way between releases, so that they those docs are better suited > for generating diffs between releases. Currently we use the boot JDK to run > javadoc for these, but this has shown to be problematic. This patch > introduced a specific configure parameter for the JDK to use just for > generating these docs. If not set, it will revert to the default interim > javadoc, just like the main docs are built (but still with a separate set of > parameters). > > This fix needs to go into JDK 16 so that the docs-reference target there can > be used to generate diffs for JDK 17. Do you need to update the copyright year? Other than that, your changes appear to implement the described behaviour. Thanks! Iris - Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/88
Re: [jdk16] RFR: JDK-8258657: Doc build is broken by use of new language features
On Tue, 5 Jan 2021 22:51:29 GMT, Erik Joelsson wrote: > This patch changes how the docs-reference make target behaves to better > support the requirements for it. This target is used to generate javadocs in > a more stable way between releases, so that they those docs are better suited > for generating diffs between releases. Currently we use the boot JDK to run > javadoc for these, but this has shown to be problematic. This patch > introduced a specific configure parameter for the JDK to use just for > generating these docs. If not set, it will revert to the default interim > javadoc, just like the main docs are built (but still with a separate set of > parameters). > > This fix needs to go into JDK 16 so that the docs-reference target there can > be used to generate diffs for JDK 17. Marked as reviewed by tbell (Reviewer). Marked as reviewed by tbell (Reviewer). Marked as reviewed by tbell (Reviewer). - PR: https://git.openjdk.java.net/jdk16/pull/88
Integrated: 8247957: remove doclint support for HTML 4
On Wed, 28 Oct 2020 03:26:16 GMT, Yoshiki Sato wrote: > HTML4 is no longer supported in javadoc. > > doclint needs to drop HTML4 support as well. > The changes consist of: > * Removing -Xhtmlversion option from doclint and --doclint-format from javac. > * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references. > * Updating makefile not to use removed option. > * Sorting out supported tags and attributes in HTML5 (including fix incorrect > permission of valign in TH, TR, TD, THEAD and TBODY) > * Fixing incorrect value checks for the id attribute. > * Modifying test code and expected outputs to be checked in HTML5 This pull request has now been integrated. Changeset: 28e1f4d9 Author:Yoshiki Sato Committer: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/28e1f4d9 Stats: 1499 lines in 60 files changed: 411 ins; 808 del; 280 mod 8247957: remove doclint support for HTML 4 8257204: Remove usage of -Xhtmlversion option from javac 8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option 8258460: Remove --doclint-format option from javac 8256312: Valid anchor 'id' value not allowed Reviewed-by: jjg, ihse - PR: https://git.openjdk.java.net/jdk/pull/893
Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v2]
On Wed, 6 Jan 2021 13:24:22 GMT, Hao Sun wrote: >> @vnkozlov I was wondering if you could take a look at this? We're not sure >> whether 'operator=' is problematic or not. Thanks. > > I manually checked the usages of assignment operators for class DUIterator, > DUIterator_Fast and DUIterator_Last. (Simply grep the class names in the > source code and check the context). > > ~~I found there exist only a couple of re-assignment usages. However, I guess > kind of reset operations are conducted in these sites, and I suspect the > implementation of `operator=` might be good.~~ > > As I examined, only the following 3 sites are found where re-assignment > happens > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/cfgnode.cpp#L565 > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/phaseX.cpp#L1878 > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/split_if.cpp#L452 > > Please take `cfgnode.cpp` as an example. `j` is first assigned at line 568 > and it would be assigned again if flag `progress` is true. ~~However, I > suppose `j` gets reset at line 578 in such case.~~ Note that `j` might be > re-assigned at line 578. However, it's self assignment and nothing is > conducted. > > ~~It might be incorrect if I missed something.~~ > Hope that this finding would be helpful to analyze this problem. Code is correct. _last should not be updated with additional assignments which updates only node's information. - PR: https://git.openjdk.java.net/jdk/pull/1874
Re: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale
On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote: > I got garbled exception message as following when I run `livenmethods` CLHSDB > command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???W > > My Windows laptop is set Japanese Locale, garbled message was written in > Japanese. > saproc.dll would throw exception via > [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) > JNI function, but it accepts UTF-8 encoded message. However > [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) > Windows API might not return UTF-8 encoded string on Japanese locale. > > java.dll (libjava,so) provides good functions to resolve this issue. We can > convert localized (non ascii) chars to UTF-8 string. I use them in this PR > and remove `FormatMessage()` call from sadis.c. > And also I remove `-D_MBCS` from compiler option because [MBCS has been > already > deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) > - it does not seem to add to any other executables. Marked as reviewed by cjplummer (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1928
Integrated: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later
On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote: > Updating to the symbol files for JDK 16 b30; change generated with the script > > make/scripts/generate-symbol-data.sh > > The change to the java.desktop module looks to be for JDK-8258373. This pull request has now been integrated. Changeset: d20d2fa9 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/d20d2fa9 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Reviewed-by: iris, erikj - PR: https://git.openjdk.java.net/jdk/pull/1954
Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v2]
On Wed, 6 Jan 2021 04:34:36 GMT, Hao Sun wrote: >> Thanks for your explanation. Yes, you're right. I didn't realize the >> re-assignment scenario. > > @vnkozlov I was wondering if you could take a look at this? We're not sure > whether 'operator=' is problematic or not. Thanks. I manually checked the usages of assignment operators for class DUIterator, DUIterator_Fast and DUIterator_Last. (Simply grep the class names in the source code and check the context). ~~I found there exist only a couple of re-assignment usages. However, I guess kind of reset operations are conducted in these sites, and I suspect the implementation of `operator=` might be good.~~ As I examined, only the following 3 sites are found where re-assignment happens https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/cfgnode.cpp#L565 https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/phaseX.cpp#L1878 https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/split_if.cpp#L452 Please take `cfgnode.cpp` as an example. `j` is first assigned at line 568 and it would be assigned again if flag `progress` is true. ~~However, I suppose `j` gets reset at line 578 in such case.~~ Note that `j` might be re-assigned at line 578. However, it's self assignment and nothing is conducted. ~~It might be incorrect if I missed something.~~ Hope that this finding would be helpful to analyze this problem. - PR: https://git.openjdk.java.net/jdk/pull/1874
Re: RFR: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later
On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote: > Updating to the symbol files for JDK 16 b30; change generated with the script > > make/scripts/generate-symbol-data.sh > > The change to the java.desktop module looks to be for JDK-8258373. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1954
