Integrated: 8266974: duplicate property key in java.sql.rowset resource bundle
On Tue, 25 Jan 2022 10:47:41 GMT, Masanori Yano wrote: > I have removed the duplicate property keys. > Could you please review the fix? This pull request has now been integrated. Changeset: e3d5c9e7 Author:Masanori Yano Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/e3d5c9e7c4ab210ae7a4417a47632603910744a1 Stats: 22 lines in 11 files changed: 0 ins; 11 del; 11 mod 8266974: duplicate property key in java.sql.rowset resource bundle Reviewed-by: lancea - PR: https://git.openjdk.java.net/jdk/pull/7212
Re: RFR: 8266974: duplicate property key in java.sql.rowset resource bundle
On Tue, 25 Jan 2022 11:25:55 GMT, Lance Andersen wrote: >> I have removed the duplicate property keys. >> Could you please review the fix? > > Marked as reviewed by lancea (Reviewer). @LanceAndersen Could you please commit this fix as a sponsor? - PR: https://git.openjdk.java.net/jdk/pull/7212
RFR: 8266974: duplicate property key in java.sql.rowset resource bundle
I have removed the duplicate property keys. Could you please review the fix? - Commit messages: - 8266974: duplicate property key in java.sql.rowset resource bundle Changes: https://git.openjdk.java.net/jdk/pull/7212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7212=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266974 Stats: 22 lines in 11 files changed: 0 ins; 11 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7212/head:pull/7212 PR: https://git.openjdk.java.net/jdk/pull/7212
Integrated: 8272746: ZipFile can't open big file (NegativeArraySizeException)
On Thu, 23 Dec 2021 10:55:08 GMT, Masanori Yano wrote: > Could you please review the JDK-8272746 bug fixes? > Since the array index is of type int, the overflow occurs when the value of > end.cenlen is too large because of too many entries. > It is necessary to read a part of the CEN from the file to fix the problem > fundamentally, but the way will require an extensive fix and degrade > performance. > In practical terms, the size of the central directory rarely grows that > large. So, I fixed it to check the size of the central directory and throw an > exception if it is too large. This pull request has now been integrated. Changeset: 848b16a3 Author:Masanori Yano Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/848b16a3f933c1cffbce93337a5d9b4e48ce4b45 Stats: 92 lines in 2 files changed: 92 ins; 0 del; 0 mod 8272746: ZipFile can't open big file (NegativeArraySizeException) Reviewed-by: lancea - PR: https://git.openjdk.java.net/jdk/pull/6927
Integrated: 8278892: java.naming module description is missing @uses tags to document the services that it uses
On Wed, 12 Jan 2022 05:48:26 GMT, Masanori Yano wrote: > I have fixed the javadoc comments as the definition. Could you review this > fix? This pull request has now been integrated. Changeset: 94522626 Author:Masanori Yano Committer: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/945226265234b790b175ea312f7af1126984db68 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8278892: java.naming module description is missing @uses tags to document the services that it uses Reviewed-by: aefimov, alanb - PR: https://git.openjdk.java.net/jdk/pull/7041
Re: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v4]
On Mon, 17 Jan 2022 18:10:02 GMT, Lance Andersen wrote: >> Masanori Yano has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8272746: ZipFile can't open big file (NegativeArraySizeException) > > test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java line 82: > >> 80: >> 81: /** >> 82: * Validates that an appropriate exception is thrown when the >> ZipFile class > > Please change "appropriate" to "ZipException" Thank you very much. I fixed it. - PR: https://git.openjdk.java.net/jdk/pull/6927
Re: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v5]
> Could you please review the JDK-8272746 bug fixes? > Since the array index is of type int, the overflow occurs when the value of > end.cenlen is too large because of too many entries. > It is necessary to read a part of the CEN from the file to fix the problem > fundamentally, but the way will require an extensive fix and degrade > performance. > In practical terms, the size of the central directory rarely grows that > large. So, I fixed it to check the size of the central directory and throw an > exception if it is too large. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8272746: ZipFile can't open big file (NegativeArraySizeException) - Changes: - all: https://git.openjdk.java.net/jdk/pull/6927/files - new: https://git.openjdk.java.net/jdk/pull/6927/files/9ebb2a7a..c6b53732 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6927=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6927=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927 PR: https://git.openjdk.java.net/jdk/pull/6927
Re: RFR: 8278892: java.naming module description is missing @uses tags to document the services that it uses
On Wed, 12 Jan 2022 05:48:26 GMT, Masanori Yano wrote: > I have fixed the javadoc comments as the definition. Could you review this > fix? Could someone please review this pull request? - PR: https://git.openjdk.java.net/jdk/pull/7041
Re: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v4]
> Could you please review the JDK-8272746 bug fixes? > Since the array index is of type int, the overflow occurs when the value of > end.cenlen is too large because of too many entries. > It is necessary to read a part of the CEN from the file to fix the problem > fundamentally, but the way will require an extensive fix and degrade > performance. > In practical terms, the size of the central directory rarely grows that > large. So, I fixed it to check the size of the central directory and throw an > exception if it is too large. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8272746: ZipFile can't open big file (NegativeArraySizeException) - Changes: - all: https://git.openjdk.java.net/jdk/pull/6927/files - new: https://git.openjdk.java.net/jdk/pull/6927/files/621f1a68..9ebb2a7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6927=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6927=02-03 Stats: 14 lines in 1 file changed: 12 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927 PR: https://git.openjdk.java.net/jdk/pull/6927
Re: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v3]
On Fri, 14 Jan 2022 23:55:58 GMT, Lance Andersen wrote: >> Masanori Yano has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8272746: ZipFile can't open big file (NegativeArraySizeException) > > Thank you for making the changes. Overall it looks much better > > Please add comments describing your constants as well as a comment describing > the intent of your setup and test methods @LanceAndersen As you pointed out, I described the explanation of the test in the comment. Is there anything else I should fix? - PR: https://git.openjdk.java.net/jdk/pull/6927
Re: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v3]
> Could you please review the JDK-8272746 bug fixes? > Since the array index is of type int, the overflow occurs when the value of > end.cenlen is too large because of too many entries. > It is necessary to read a part of the CEN from the file to fix the problem > fundamentally, but the way will require an extensive fix and degrade > performance. > In practical terms, the size of the central directory rarely grows that > large. So, I fixed it to check the size of the central directory and throw an > exception if it is too large. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8272746: ZipFile can't open big file (NegativeArraySizeException) - Changes: - all: https://git.openjdk.java.net/jdk/pull/6927/files - new: https://git.openjdk.java.net/jdk/pull/6927/files/c54c50eb..621f1a68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6927=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6927=01-02 Stats: 33 lines in 1 file changed: 10 ins; 9 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927 PR: https://git.openjdk.java.net/jdk/pull/6927
Re: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v2]
On Sat, 8 Jan 2022 16:09:59 GMT, Lance Andersen wrote: >> Masanori Yano has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8272746: ZipFile can't open big file (NegativeArraySizeException) > > Thank you for your work here. Have you also run your test using Apache > Commons? > > I have run this test over 2000 times via Mach5 on various hardware with some > runs taking over 12 minutes for the test to complete. So unless you can > refactor the test to be more efficient, we need to make the test a manual > test as this is more of a corner case. > > Please see the additional comments below @LanceAndersen Thank you for your detailed comments. I converted the test to use TestNG as you pointed out. Could you please review it again? - PR: https://git.openjdk.java.net/jdk/pull/6927
RFR: 8278892: java.naming module description is missing @uses tags to document the services that it uses
I have fixed the javadoc comments as the definition. Could you review this fix? - Commit messages: - 8278892: java.naming module description is missing @uses tags to document the services that it uses Changes: https://git.openjdk.java.net/jdk/pull/7041/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7041=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278892 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7041.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7041/head:pull/7041 PR: https://git.openjdk.java.net/jdk/pull/7041
Integrated: 8276694: Pattern trailing unescaped backslash causes internal error
On Mon, 20 Dec 2021 09:57:14 GMT, Masanori Yano wrote: > Could you please review the 8276694 bug fixes? > > A message specific for this exception should be printed instead of an > internal error. This fix adds a new check to output an appropriate exception > message when the regular expression ends with an unescaped backslash. This > fix also checks the position of the cursor to rule out other syntax errors at > the middle position of the regular expression. This pull request has now been integrated. Changeset: 3aaa0982 Author:Masanori Yano Committer: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/3aaa0982d8c1735208a331b0097a5aea4a1fef5a Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod 8276694: Pattern trailing unescaped backslash causes internal error Reviewed-by: jlaskey - PR: https://git.openjdk.java.net/jdk/pull/6891
Re: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v2]
On Thu, 23 Dec 2021 16:42:50 GMT, Alan Bateman wrote:
>> Masanori Yano has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8272746: ZipFile can't open big file (NegativeArraySizeException)
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1501:
>
>> 1499: // read in the CEN and END
>> 1500: if (end.cenlen + ENDHDR >= Integer.MAX_VALUE) {
>> 1501: zerror("invalid END header (too large central
>> directory size)");
>
> This check looks correct. It might be a bit clearer to say that "central
> directory size too large" rather than "too large central directory size".
>
> The bug report says that JDK 8 and the native zip handle these zip files,
> were you able to check that?
@AlanBateman Could you please review the above comments.
-
PR: https://git.openjdk.java.net/jdk/pull/6927
Re: RFR: 8276694: Pattern trailing unescaped backslash causes internal error
On Mon, 20 Dec 2021 09:57:14 GMT, Masanori Yano wrote: > Could you please review the 8276694 bug fixes? > > A message specific for this exception should be printed instead of an > internal error. This fix adds a new check to output an appropriate exception > message when the regular expression ends with an unescaped backslash. This > fix also checks the position of the cursor to rule out other syntax errors at > the middle position of the regular expression. Could someone please review this pull request? - PR: https://git.openjdk.java.net/jdk/pull/6891
Re: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v2]
On Thu, 23 Dec 2021 16:42:50 GMT, Alan Bateman wrote:
>> Masanori Yano has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8272746: ZipFile can't open big file (NegativeArraySizeException)
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1501:
>
>> 1499: // read in the CEN and END
>> 1500: if (end.cenlen + ENDHDR >= Integer.MAX_VALUE) {
>> 1501: zerror("invalid END header (too large central
>> directory size)");
>
> This check looks correct. It might be a bit clearer to say that "central
> directory size too large" rather than "too large central directory size".
>
> The bug report says that JDK 8 and the native zip handle these zip files,
> were you able to check that?
I will correct the message as you pointed out.
I checked the JDK8 and Linux unzip commands and found no exceptions or errors.
Since JDK9, [JDK-8145260](https://bugs.openjdk.java.net/browse/JDK-8145260) has
been modified to significantly change the way zip files are handled, resulting
in a different result than jdk8.
-
PR: https://git.openjdk.java.net/jdk/pull/6927
Re: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v2]
> Could you please review the JDK-8272746 bug fixes? > Since the array index is of type int, the overflow occurs when the value of > end.cenlen is too large because of too many entries. > It is necessary to read a part of the CEN from the file to fix the problem > fundamentally, but the way will require an extensive fix and degrade > performance. > In practical terms, the size of the central directory rarely grows that > large. So, I fixed it to check the size of the central directory and throw an > exception if it is too large. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8272746: ZipFile can't open big file (NegativeArraySizeException) - Changes: - all: https://git.openjdk.java.net/jdk/pull/6927/files - new: https://git.openjdk.java.net/jdk/pull/6927/files/a85ef0f5..c54c50eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6927=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6927=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927 PR: https://git.openjdk.java.net/jdk/pull/6927
RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException)
Could you please review the JDK-8272746 bug fixes? Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries. It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance. In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large. - Commit messages: - 8272746: ZipFile can't open big file (NegativeArraySizeException) Changes: https://git.openjdk.java.net/jdk/pull/6927/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6927=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272746 Stats: 80 lines in 2 files changed: 80 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927 PR: https://git.openjdk.java.net/jdk/pull/6927
RFR: 8276694: Pattern trailing unescaped backslash causes internal error
Could you please review the 8276694 bug fixes? A message specific for this exception should be printed instead of an internal error. This fix adds a new check to output an appropriate exception message when the regular expression ends with an unescaped backslash. This fix also checks the position of the cursor to rule out other syntax errors at the middle position of the regular expression. - Commit messages: - 8276694: Pattern trailing unescaped backslash causes internal error Changes: https://git.openjdk.java.net/jdk/pull/6891/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6891=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276694 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6891/head:pull/6891 PR: https://git.openjdk.java.net/jdk/pull/6891
Integrated: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Fri, 24 Sep 2021 11:28:09 GMT, Masanori Yano wrote: > Could you please review the 8250678 bug fixes? > > The `parse` method of ModuleDescriptor.Version class behaves incorrectly when > the input string contains consecutive delimiters. > > The `parse` method treats strings as three sections, but the parsing method > differs between the method for the version sections and the ones for others. > In version sections, the `parse` method takes a single character in a loop > and determines whether it is a delimiter. In pre and build sections, the > parse method takes two characters in a loop and determines whether the second > character is the delimiter. Therefore, if the string contains a sequence of > delimiters in pre or build section, the `parse` method treats character at > the odd-numbered position as a token and the one at even-numbered as a > delimiter. > > A string containing consecutive delimiters is an incorrect version string, > but this behavior does not follow the API specification. > https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html > > Therefore, I propose to fix the parsing method of pre and build section in > the same way as the version. This pull request has now been integrated. Changeset: e1985947 Author:Masanori Yano Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/e198594753b0b0653256923586c7f4ec9e3cfac3 Stats: 26 lines in 2 files changed: 11 ins; 14 del; 1 mod 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Reviewed-by: mchung, alanb - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Fri, 24 Sep 2021 11:28:09 GMT, Masanori Yano wrote: > Could you please review the 8250678 bug fixes? > > The `parse` method of ModuleDescriptor.Version class behaves incorrectly when > the input string contains consecutive delimiters. > > The `parse` method treats strings as three sections, but the parsing method > differs between the method for the version sections and the ones for others. > In version sections, the `parse` method takes a single character in a loop > and determines whether it is a delimiter. In pre and build sections, the > parse method takes two characters in a loop and determines whether the second > character is the delimiter. Therefore, if the string contains a sequence of > delimiters in pre or build section, the `parse` method treats character at > the odd-numbered position as a token and the one at even-numbered as a > delimiter. > > A string containing consecutive delimiters is an incorrect version string, > but this behavior does not follow the API specification. > https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html > > Therefore, I propose to fix the parsing method of pre and build section in > the same way as the version. Thank you for reviewing. Does clarifying the spec in this PR mean modifying the comments in javadoc? - PR: https://git.openjdk.java.net/jdk/pull/5679
Integrated: 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc
On Fri, 29 Oct 2021 10:37:07 GMT, Masanori Yano wrote: > Could you please review the 8276164 bug fixes? > > I suggest adding the missing javadoc of `@throws IndexOutOfBoundsException`. This pull request has now been integrated. Changeset: 9bf31652 Author: Masanori Yano Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/9bf31652cbe8eb2699babe5e52e62ea1f1578588 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/6168
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Wed, 6 Oct 2021 18:40:36 GMT, Mark Reinhold wrote: >> @mbreinhold Could you comment on this pull request? > >> @mbreinhold Could you comment on this pull request? > > This is somewhat tricky code. I’ll take a look, but give me a few days. @mbreinhold @AlanBateman Are you aware of my comment? Could you please reply? - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc [v2]
> Could you please review the 8276164 bug fixes? > > I suggest adding the missing javadoc of `@throws IndexOutOfBoundsException`. Masanori Yano has updated the pull request incrementally with two additional commits since the last revision: - 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc - 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc - Changes: - all: https://git.openjdk.java.net/jdk/pull/6168/files - new: https://git.openjdk.java.net/jdk/pull/6168/files/bf4b0e25..a1cf0531 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6168=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6168=00-01 Stats: 7 lines in 2 files changed: 3 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6168/head:pull/6168 PR: https://git.openjdk.java.net/jdk/pull/6168
RFR: 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc
Could you please review the 8276164 bug fixes? I suggest adding the missing javadoc of `@throws IndexOutOfBoundsException`. - Commit messages: - 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Changes: https://git.openjdk.java.net/jdk/pull/6168/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6168=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276164 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6168/head:pull/6168 PR: https://git.openjdk.java.net/jdk/pull/6168
Re: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException [v2]
> Could you please review the 8262297 bug fixes? > > In this case, ImageIO.write() should throw java.io.IOException rather than > java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and > wrapped in IIOException in ImageIO.write() with this fix. In addition, > IndexOutOfBoundsException is not expected to throw by > RandomAccessFile#write() according to its API specification. So it should be > fixed. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException - Changes: - all: https://git.openjdk.java.net/jdk/pull/6151/files - new: https://git.openjdk.java.net/jdk/pull/6151/files/d6a652fa..08b54fff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6151=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6151=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151 PR: https://git.openjdk.java.net/jdk/pull/6151
Re: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
On Fri, 29 Oct 2021 07:13:32 GMT, Alan Bateman wrote: >> Unfortunately the parent class does not specify this exception via javadoc >> tags like "@throws IndexOutOfBoundsException", but instead just describe it >> in the method description >> >> should we fix it separately from the imageio fix? > >> Unfortunately the parent class does not specify this exception via javadoc >> tags like "@throws IndexOutOfBoundsException", but instead just describe it >> in the method description >> >> should we fix it separately from the imageio fix? > > Yes, it might be better to separate them because we'll like need a CSR if we > are missing @throws in a few places. I understood to separate javadoc fix. I will remove the javadoc fix from this PR and issue another Bug ID. - PR: https://git.openjdk.java.net/jdk/pull/6151
Withdrawn: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short > time, so CreateFile() should be retried. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/5460
Re: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short > time, so CreateFile() should be retried. Thank you for your reply. I understand we have no need to fix the JDK. I will close this pull request. - PR: https://git.openjdk.java.net/jdk/pull/5460
RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
Could you please review the 8262297 bug fixes? In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed. - Commit messages: - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException Changes: https://git.openjdk.java.net/jdk/pull/6151/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6151=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262297 Stats: 96 lines in 4 files changed: 71 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/6151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151 PR: https://git.openjdk.java.net/jdk/pull/6151
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Wed, 6 Oct 2021 18:40:36 GMT, Mark Reinhold wrote: >> @mbreinhold Could you comment on this pull request? > >> @mbreinhold Could you comment on this pull request? > > This is somewhat tricky code. I’ll take a look, but give me a few days. @mbreinhold @AlanBateman Could you please reply to the above comments? - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Mon, 27 Sep 2021 08:22:02 GMT, Alan Bateman wrote: >> Could you please review the 8250678 bug fixes? >> >> The `parse` method of ModuleDescriptor.Version class behaves incorrectly >> when the input string contains consecutive delimiters. >> >> The `parse` method treats strings as three sections, but the parsing method >> differs between the method for the version sections and the ones for others. >> In version sections, the `parse` method takes a single character in a loop >> and determines whether it is a delimiter. In pre and build sections, the >> parse method takes two characters in a loop and determines whether the >> second character is the delimiter. Therefore, if the string contains a >> sequence of delimiters in pre or build section, the `parse` method treats >> character at the odd-numbered position as a token and the one at >> even-numbered as a delimiter. >> >> A string containing consecutive delimiters is an incorrect version string, >> but this behavior does not follow the API specification. >> https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html >> >> Therefore, I propose to fix the parsing method of pre and build section in >> the same way as the version. > > I think this is okay, just maybe unusual to have repeated punctuation > creating the case where a component is empty. @mbreinhold may wish to comment > on this PR. @AlanBateman I have been waiting for a reply from @mbreinhold , but I haven't received it yet. I would like to contribute this PR as soon as possible. Do you have any ideas on how to do it? - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Wed, 6 Oct 2021 18:40:36 GMT, Mark Reinhold wrote: >> @mbreinhold Could you comment on this pull request? > >> @mbreinhold Could you comment on this pull request? > > This is somewhat tricky code. I’ll take a look, but give me a few days. @mbreinhold (@AlanBateman ) Could you tell me how many more days do you need for your confirmation? - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
On Mon, 27 Sep 2021 08:04:23 GMT, Alan Bateman wrote: >> It’s a good idea to ask the Microsoft folks about that, but I don't know the >> way to ask. Could you tell me how to do it? >> >> As you say, CreateFile function is used in other parts of the JDK, but it >> have a significant impact to fix all of that. Therefore, I fixed the problem >> about opening zip files and jar files which is reported in the JBS. > >> It’s a good idea to ask the Microsoft folks about that, but I don't know the >> way to ask. Could you tell me how to do it? >> >> As you say, CreateFile function is used in other parts of the JDK, but it >> have a significant impact to fix all of that. Therefore, I fixed the problem >> about opening zip files and jar files which is reported in the JBS. > > I think we need to find out if the issue you are working around is a > bug/issue with the virus checker or that Microsoft recommends that all > applications should put a retry to work around these issues. As regards the > patch then it is incomplete. If we are forced to put a workaround into the > JDK code then I think it will have to do everywhere, not just for zip/JAR > files. @AlanBateman Could you reply to the above comment? - PR: https://git.openjdk.java.net/jdk/pull/5460
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Wed, 6 Oct 2021 18:40:36 GMT, Mark Reinhold wrote: >> @mbreinhold Could you comment on this pull request? > >> @mbreinhold Could you comment on this pull request? > > This is somewhat tricky code. I’ll take a look, but give me a few days. @mbreinhold I waited for about a week, but I haven't received an answer yet. Could you comment on this? - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short > time, so CreateFile() should be retried. I inquired of the Microsoft Technical Support about this problem. They said that using a simple retry mechanism is the effective workaround for this problem as in the article. But, they are not sure which is wrong the application or the virus checker because it depends on the situation. Which method do you think is better, to fix the JDK or to change the configuration of the virus checker? - PR: https://git.openjdk.java.net/jdk/pull/5460
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Mon, 27 Sep 2021 08:22:02 GMT, Alan Bateman wrote: >> Could you please review the 8250678 bug fixes? >> >> The `parse` method of ModuleDescriptor.Version class behaves incorrectly >> when the input string contains consecutive delimiters. >> >> The `parse` method treats strings as three sections, but the parsing method >> differs between the method for the version sections and the ones for others. >> In version sections, the `parse` method takes a single character in a loop >> and determines whether it is a delimiter. In pre and build sections, the >> parse method takes two characters in a loop and determines whether the >> second character is the delimiter. Therefore, if the string contains a >> sequence of delimiters in pre or build section, the `parse` method treats >> character at the odd-numbered position as a token and the one at >> even-numbered as a delimiter. >> >> A string containing consecutive delimiters is an incorrect version string, >> but this behavior does not follow the API specification. >> https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html >> >> Therefore, I propose to fix the parsing method of pre and build section in >> the same way as the version. > > I think this is okay, just maybe unusual to have repeated punctuation > creating the case where a component is empty. @mbreinhold may wish to comment > on this PR. @AlanBateman I can't seem to get a comment on this PR from @mbreinhold , so could you please review it? - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Fri, 24 Sep 2021 11:28:09 GMT, Masanori Yano wrote: > Could you please review the 8250678 bug fixes? > > The `parse` method of ModuleDescriptor.Version class behaves incorrectly when > the input string contains consecutive delimiters. > > The `parse` method treats strings as three sections, but the parsing method > differs between the method for the version sections and the ones for others. > In version sections, the `parse` method takes a single character in a loop > and determines whether it is a delimiter. In pre and build sections, the > parse method takes two characters in a loop and determines whether the second > character is the delimiter. Therefore, if the string contains a sequence of > delimiters in pre or build section, the `parse` method treats character at > the odd-numbered position as a token and the one at even-numbered as a > delimiter. > > A string containing consecutive delimiters is an incorrect version string, > but this behavior does not follow the API specification. > https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html > > Therefore, I propose to fix the parsing method of pre and build section in > the same way as the version. @mbreinhold Could you comment on this pull request? - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short > time, so CreateFile() should be retried. It’s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it? As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS. - PR: https://git.openjdk.java.net/jdk/pull/5460
RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
Could you please review the 8250678 bug fixes? The `parse` method of ModuleDescriptor.Version class behaves incorrectly when the input string contains consecutive delimiters. The `parse` method treats strings as three sections, but the parsing method differs between the method for the version sections and the ones for others. In version sections, the `parse` method takes a single character in a loop and determines whether it is a delimiter. In pre and build sections, the parse method takes two characters in a loop and determines whether the second character is the delimiter. Therefore, if the string contains a sequence of delimiters in pre or build section, the `parse` method treats character at the odd-numbered position as a token and the one at even-numbered as a delimiter. A string containing consecutive delimiters is an incorrect version string, but this behavior does not follow the API specification. https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html Therefore, I propose to fix the parsing method of pre and build section in the same way as the version. - Commit messages: - 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Changes: https://git.openjdk.java.net/jdk/pull/5679/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5679=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250678 Stats: 26 lines in 2 files changed: 11 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5679.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5679/head:pull/5679 PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short > time, so CreateFile() should be retried. Thank you for your comment. According to Microsoft KB316609, CreateFile() should be tried again a short time later. I think JarURLConnection should also be retried when antivirus software holds some files. https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/316609 - PR: https://git.openjdk.java.net/jdk/pull/5460
RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
Could you please review the 8233674 bug fixes? This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried. - Commit messages: - 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file Changes: https://git.openjdk.java.net/jdk/pull/5460/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5460=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233674 Stats: 299 lines in 3 files changed: 261 ins; 12 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/5460.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5460/head:pull/5460 PR: https://git.openjdk.java.net/jdk/pull/5460
Integrated: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform
On Fri, 25 Jun 2021 12:10:18 GMT, Masanori Yano wrote: > Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg > command option. To run non-localized tests, -Duser.language=en and > -Duser.country=US options should be added in ProcessBuilder. This pull request has now been integrated. Changeset: cb112aff Author:Masanori Yano Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/cb112affd6061e8ace6dad4e92c7b394a413e37f Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform Reviewed-by: naoto - PR: https://git.openjdk.java.net/jdk/pull/4594
Re: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v5]
> Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg > command option. To run non-localized tests, -Duser.language=en and > -Duser.country=US options should be added in ProcessBuilder. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform - Changes: - all: https://git.openjdk.java.net/jdk/pull/4594/files - new: https://git.openjdk.java.net/jdk/pull/4594/files/98e7cfcb..b5a46b4a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4594=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4594=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594
Re: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v4]
> Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg > command option. To run non-localized tests, -Duser.language=en and > -Duser.country=US options should be added in ProcessBuilder. Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into 8269373 - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform - 8269373: use test opts for process arguments - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform - Changes: https://git.openjdk.java.net/jdk/pull/4594/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4594=03 Stats: 15 lines in 3 files changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594
Re: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v3]
On Tue, 7 Sep 2021 11:12:56 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg >> command option. To run non-localized tests, -Duser.language=en and >> -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional > commit since the last revision: > > 8269373: some tests in jdk/tools/launcher/ fails on localized Windows > platform I fixed it to exit silently in case the locale is not US. Thank you. - PR: https://git.openjdk.java.net/jdk/pull/4594
Re: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v3]
> Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg > command option. To run non-localized tests, -Duser.language=en and > -Duser.country=US options should be added in ProcessBuilder. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform - Changes: - all: https://git.openjdk.java.net/jdk/pull/4594/files - new: https://git.openjdk.java.net/jdk/pull/4594/files/99925f72..655f5db0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4594=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4594=01-02 Stats: 31 lines in 6 files changed: 16 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594
Re: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2]
On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg >> command option. To run non-localized tests, -Duser.language=en and >> -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional > commit since the last revision: > > 8269373: use test opts for process arguments I think the current tests force the US locale, and false positives are test failures in non-US locale environments. This fix does not change the test results in the US locale, but allows it to work in non-US locale environments. I can't think of a false positive problem with this fix, but what specific cases do you think are the problems? - PR: https://git.openjdk.java.net/jdk/pull/4594
Re: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2]
On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg >> command option. To run non-localized tests, -Duser.language=en and >> -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional > commit since the last revision: > > 8269373: use test opts for process arguments It is true that some other tests say Passed if the locale is not US, but I rather think that is not a good way. I think we should run tests as much as possible to ensure quality even in non-US environments. - PR: https://git.openjdk.java.net/jdk/pull/4594
Re: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2]
On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg >> command option. To run non-localized tests, -Duser.language=en and >> -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional > commit since the last revision: > > 8269373: use test opts for process arguments Sorry for late reply. These tests compare the output of running the jar, and the correct answers to the output results are written in English. When these are run on localized Windows platform, the output will be in the local language and the comparison result will be false. So, these need to add -Duser.language=en and -Duser.country=US to the execution option of the jar. And I fixed to avoid hardcoding by using "test.vm.opts". If we want to run these tests on localized Windows platform, we need to add -Duser.language=en and -Duser.country=US as jtreg command options. - PR: https://git.openjdk.java.net/jdk/pull/4594
Re: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2]
> Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg > command option. To run non-localized tests, -Duser.language=en and > -Duser.country=US options should be added in ProcessBuilder. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8269373: use test opts for process arguments - Changes: - all: https://git.openjdk.java.net/jdk/pull/4594/files - new: https://git.openjdk.java.net/jdk/pull/4594/files/e5546ded..99925f72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4594=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4594=00-01 Stats: 14 lines in 6 files changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594
Integrated: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML
On Fri, 11 Jun 2021 12:42:35 GMT, Masanori Yano wrote: > Hi all, > > Could you please review the 8268457 bug fixes? > > The problem is that ToHTMLStream applies processing for non-surrogate pairs > to the surrogate pair. > This fix changes the processing for non-surrogate pairs to the else condition. This pull request has now been integrated. Changeset: 83bce94c Author:Masanori Yano Committer: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/83bce94cc8a7fb45b0604598411fbecc62000dfd Stats: 194 lines in 7 files changed: 168 ins; 21 del; 5 mod 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML Reviewed-by: lancea, naoto, iris, joehw - PR: https://git.openjdk.java.net/jdk/pull/4474
RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform
Hi all, Could you please review the 8269373 bug fixes? These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. - Commit messages: - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform Changes: https://git.openjdk.java.net/jdk/pull/4594/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4594=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269373 Stats: 14 lines in 6 files changed: 5 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594
Re: RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML [v2]
On Fri, 18 Jun 2021 20:28:06 GMT, Naoto Sato wrote: >> Masanori Yano has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reflect the review comments > > test/jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest1.xml line 4: > >> 2: >> 3: ட >> 4: > > Add a new line at the end of the file (and other newly created files too). I added a new line at the end of every new file. - PR: https://git.openjdk.java.net/jdk/pull/4474
Re: RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML [v3]
On Fri, 18 Jun 2021 21:09:39 GMT, Joe Wang wrote: >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java >> line 1454: >> >>> 1452: writer.write(ch); // no escaping in this case >>> 1453: } >>> 1454: else >> >> I was suggesting removing the entire comment-out block if it is not needed >> (and confusing), but I will defer the decision to Joe. > > I agree. It's very obsolete. The comment-out block from line 1445 to 1454 can > be removed. I was mistaken. I deleted the entire comment. - PR: https://git.openjdk.java.net/jdk/pull/4474
Re: RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML [v3]
> Hi all, > > Could you please review the 8268457 bug fixes? > > The problem is that ToHTMLStream applies processing for non-surrogate pairs > to the surrogate pair. > This fix changes the processing for non-surrogate pairs to the else condition. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: remove unnecessally comments and add eof line - Changes: - all: https://git.openjdk.java.net/jdk/pull/4474/files - new: https://git.openjdk.java.net/jdk/pull/4474/files/d5792a87..1183c2f6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4474=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4474=01-02 Stats: 14 lines in 4 files changed: 0 ins; 11 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4474/head:pull/4474 PR: https://git.openjdk.java.net/jdk/pull/4474
Re: RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML
On Fri, 11 Jun 2021 12:42:35 GMT, Masanori Yano wrote: > Hi all, > > Could you please review the 8268457 bug fixes? > > The problem is that ToHTMLStream applies processing for non-surrogate pairs > to the surrogate pair. > This fix changes the processing for non-surrogate pairs to the else condition. Thank you for reviewing. I reflected the review comments to my change. - PR: https://git.openjdk.java.net/jdk/pull/4474
Re: RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML [v2]
> Hi all, > > Could you please review the 8268457 bug fixes? > > The problem is that ToHTMLStream applies processing for non-surrogate pairs > to the surrogate pair. > This fix changes the processing for non-surrogate pairs to the else condition. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: Reflect the review comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/4474/files - new: https://git.openjdk.java.net/jdk/pull/4474/files/81975b58..d5792a87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4474=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4474=00-01 Stats: 266 lines in 8 files changed: 104 ins; 160 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4474/head:pull/4474 PR: https://git.openjdk.java.net/jdk/pull/4474
RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML
Hi all, Could you please review the 8268457 bug fixes? The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair. This fix changes the processing for non-surrogate pairs to the else condition. - Commit messages: - clean up whitespace - 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML Changes: https://git.openjdk.java.net/jdk/pull/4474/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4474=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268457 Stats: 235 lines in 7 files changed: 223 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4474/head:pull/4474 PR: https://git.openjdk.java.net/jdk/pull/4474
