On Wed, 20 Apr 2022 15:48:54 GMT, Tyler Steele wrote:
>> Shruthi has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace the ER_RTF_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER key in
>> XPATHErrorResources l
On Mon, 2 May 2022 07:39:39 GMT, Shruthi wrote:
>> Shruthi has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updating last modified tag and XRTreeFragSelectWrapper.java
>
> `/integrate`
LGTM. Nicely done @shruacha1234
-
PR:
On Fri, 6 May 2022 14:33:50 GMT, Shruthi wrote:
>> Removing the Duplicate keys present in XSLTErrorResources.java and
>> XPATHErrorResources.java
>>
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one
On Mon, 2 May 2022 20:05:36 GMT, Tyler Steele wrote:
> Adds missing classpath exception to the header of two GPLv2 files.
>
> Requested
> [here](https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2022-April/013988.html).
This pull request has now been integrated.
Changes
On Wed, 4 May 2022 17:42:05 GMT, Sandhya Viswanathan
wrote:
>> Tyler Steele has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright header year
>
> Marked as reviewed by sviswanathan (Reviewer
> Adds missing classpath exception to the header of two GPLv2 files.
>
> Requested
> [here](https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2022-April/013988.html).
Tyler Steele has updated the pull request incrementally with one additional
commit since the last revisio
Adds missing classpath exception to the header of two GPLv2 files.
Requested
[here](https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2022-April/013988.html).
-
Commit messages:
- Add classpath excemption to copyright header
Changes:
On Fri, 29 Apr 2022 13:31:30 GMT, Shruthi wrote:
>> Removing the Duplicate keys present in XSLTErrorResources.java and
>> XPATHErrorResources.java
>>
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one
On Mon, 2 May 2022 07:39:39 GMT, Shruthi wrote:
>> Shruthi has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updating last modified tag and XRTreeFragSelectWrapper.java
>
> `/integrate`
@shruacha1234 Please don't integrate without
On Wed, 20 Apr 2022 15:37:13 GMT, Shruthi wrote:
> Removing the Duplicate keys present in XSLTErrorResources.java and
> XPATHErrorResources.java
>
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
@shruacha1234, a few notes specific to openJDK PRs:
- Please
On Wed, 16 Mar 2022 21:25:37 GMT, Tyler Steele wrote:
> As mentioned in the issue, I'd like to perform the following tidying on
> ClassLoader.c
>
> - Alphabetize includes.
> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
> - Replace 'return 0' with 'return NULL'.
This pu
On Fri, 18 Mar 2022 15:40:09 GMT, Tyler Steele wrote:
>> As mentioned in the issue, I'd like to perform the following tidying on
>> ClassLoader.c
>>
>> - Alphabetize includes.
>> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
>> - Replace 'return 0' with
On Fri, 18 Mar 2022 15:40:09 GMT, Tyler Steele wrote:
>> As mentioned in the issue, I'd like to perform the following tidying on
>> ClassLoader.c
>>
>> - Alphabetize includes.
>> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
>> - Replace 'return 0' with
> As mentioned in the issue, I'd like to perform the following tidying on
> ClassLoader.c
>
> - Alphabetize includes.
> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
> - Replace 'return 0' with 'return NULL'.
Tyler Steele has updated the pull request incrementally w
On Fri, 18 Mar 2022 15:13:17 GMT, Tyler Steele wrote:
>> As mentioned in the issue, I'd like to perform the following tidying on
>> ClassLoader.c
>>
>> - Alphabetize includes.
>> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
>> - Replace 'return 0' with
On Fri, 18 Mar 2022 07:43:21 GMT, Alan Bateman wrote:
>> Tyler Steele has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Improve comment
>>
>> - Reword to avoid double use of malloc(X)
>>
On Fri, 18 Mar 2022 15:25:20 GMT, ExE Boss wrote:
>> I can split down the comment if you prefer. It might be appropriate to do in
>> the as-yet-unmerged cleanup PR I have open for the same file.
>>
>> I am not sure what you mean by 'use identification'. Can you clarify?
>
> I think it’s a typo
> As mentioned in the issue, I'd like to perform the following tidying on
> ClassLoader.c
>
> - Alphabetize includes.
> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
> - Replace 'return 0' with 'return NULL'.
Tyler Steele has updated the pull request incrementally w
> As mentioned in the issue, I'd like to perform the following tidying on
> ClassLoader.c
>
> - Alphabetize includes.
> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
> - Replace 'return 0' with 'return NULL'.
Tyler Steele has updated the pull request with a new target b
On Tue, 15 Mar 2022 22:58:48 GMT, Tyler Steele wrote:
> As described in the linked issue, NullClassBytesTest fails due an
> OutOfMemoryError produced on AIX when the test calls defineClass with a byte
> array of size of 0. The native implementation of defineClass then calls
On Thu, 17 Mar 2022 14:48:09 GMT, Roger Riggs wrote:
>> src/java.base/share/native/libjava/ClassLoader.c line 102:
>>
>>> 100: }
>>> 101:
>>> 102: // On malloc(0), implementators of malloc(3) have the choice to
>>> return either
>>
>> It is confusing to mix `malloc(0)`, where you are
On Thu, 17 Mar 2022 07:46:21 GMT, Thomas Stuefe wrote:
>> src/java.base/share/native/libjava/ClassLoader.c line 106:
>>
>>> 104: // we chose the latter. (see 8283225)
>>> 105: #ifdef _AIX
>>> 106: body = (jbyte *)malloc(length == 0 ? 1 : length);
>>
>> Using AIX_ONLY this can be
gt; ### Alternatives
>
> It would be possible to address this failure by modifying the test to accept
> the OutOfMemoryError on AIX. I thought it was a better solution to modify
> ClassLoader.c to produce an OutOfMemoryError only when the system is actually
> out of memory.
>
> #
> As mentioned in the issue, I'd like to perform the following tidying on
> ClassLoader.c
>
> - Alphabetize includes.
> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
> - Replace 'return 0' with 'return NULL'.
Tyler Steele has updated the pull request incrementally w
On Thu, 17 Mar 2022 10:46:35 GMT, Thomas Stuefe wrote:
>> As mentioned in the issue, I'd like to perform the following tidying on
>> ClassLoader.c
>>
>> - Alphabetize includes.
>> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
>> - Replace 'return 0' with 'return NULL'.
>
>
As mentioned in the issue, I'd like to perform the following tidying on
ClassLoader.c
- Alphabetize includes.
- Replace 'if (ptr == 0)' with 'if (ptr == NULL)'.
- Replace 'return 0' with 'return NULL'.
-
Commit messages:
- Perform minor clean up ClassLoader.c
Changes:
On Wed, 16 Mar 2022 21:06:04 GMT, Roger Riggs wrote:
>> Hmm, maybe I misunderstand the idea behind this bug tag. Don't we want to
>> list the bug ids of any issues the test caught?
>
> Usually, the bug number implies the test was modified to cover the issue.
> Otherwise, we end up with very
On Wed, 16 Mar 2022 21:10:14 GMT, Tyler Steele wrote:
>> As described in the linked issue, NullClassBytesTest fails due an
>> OutOfMemoryError produced on AIX when the test calls defineClass with a byte
>> array of size of 0. The native implementation of defineClass then
gt; ### Alternatives
>
> It would be possible to address this failure by modifying the test to accept
> the OutOfMemoryError on AIX. I thought it was a better solution to modify
> ClassLoader.c to produce an OutOfMemoryError only when the system is actually
> out of memory.
>
> ###
On Wed, 16 Mar 2022 20:19:08 GMT, Roger Riggs wrote:
>> Tyler Steele has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - Fixes type warning.
>> - Removes unneeded ClassFormatError from ClassLoader.c
>
On Wed, 16 Mar 2022 20:17:50 GMT, Roger Riggs wrote:
>> Tyler Steele has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - Fixes type warning.
>> - Removes unneeded ClassFormatError from ClassLoader.c
>
On Wed, 16 Mar 2022 14:38:55 GMT, Thomas Stuefe wrote:
>> As described in the linked issue, NullClassBytesTest fails due an
>> OutOfMemoryError produced on AIX when the test calls defineClass with a byte
>> array of size of 0. The native implementation of defineClass then calls
>> malloc
On Wed, 16 Mar 2022 14:37:57 GMT, Thomas Stuefe wrote:
> Side note: nothing against changing 0 to NULL, but please in a separate
> cleanup patch.
I just saw this. I will separate the cleanup into a separate patch.
-
PR: https://git.openjdk.java.net/jdk/pull/7829
accept
> the OutOfMemoryError on AIX. I thought it was a better solution to modify
> ClassLoader.c to produce an OutOfMemoryError only when the system is actually
> out of memory.
>
> ### Testing
>
> This change has been tested on AIX and Linux/x86.
Tyler Steele ha
On Wed, 16 Mar 2022 14:38:55 GMT, Thomas Stuefe wrote:
> Btw, which malloc call was the problematic exactly? Cannot be the one in
> getUTF, since that one already adds len + 1 and never gets called with a zero
> length anyway.
Oh, good point. I guess it gets lost in the noise of my other
On Wed, 16 Mar 2022 14:37:57 GMT, Thomas Stuefe wrote:
> The way we solve this usually is by homogenizing malloc behavior across all
> platforms with `if (len == 0) len=1;`
Interesting! That idea didn't occur to me until after I submitted the PR. I'm
happy to test that out and see how it
As described in the linked issue, NullClassBytesTest fails due an
OutOfMemoryError produced on AIX when the test calls defineClass with a byte
array of size of 0. The native implementation of defineClass then calls malloc
with a size of 0. On AIX malloc(0) returns NULL, while on other
On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi
wrote:
>> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX.
>> The test was failed by:
>> Incorrect handling of envstrings containing NULs
>>
>> According to my investigation, this issue was happened after following
>> change was
On Thu, 24 Feb 2022 17:01:13 GMT, Roger Riggs wrote:
> Javac is compiling the source to a .class file. The contents of the
> `java.library.path` do not affect the class file generated. None of the code
> of the class is executed during compilation.
Yup. Not the best snippet to include. It is
On Thu, 24 Feb 2022 07:16:42 GMT, Thomas Stuefe wrote:
> If its the former, then the issue is that `libpath` is just outdated when we
> get around to use it? In that case, why not just re-aquiring LIBPATH when
> building up `expected`?
^This was my thought at first as well :-) but in my
On Wed, 23 Feb 2022 09:46:28 GMT, Ichiroh Takiguchi
wrote:
>> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX.
>> The test was failed by:
>> Incorrect handling of envstrings containing NULs
>>
>> According to my investigation, this issue was happened after following
>> change was
On Wed, 23 Feb 2022 10:14:44 GMT, Ichiroh Takiguchi
wrote:
>> For my curiosity, how is AIX different from other Linux in that the
>> test.nativepath is not/should not be in LIBPATH?
>
> @RogerRiggs
> Many thanks. that's good point.
> Only 1st part has `test.nativepath` because of following
On Tue, 22 Feb 2022 21:22:57 GMT, Tyler Steele wrote:
> This test had two failing sections on AIX related to an incorrect expected
> value for LIBPATH. The two (previously failing) test sections are below.
>
> - Test Runtime.exec(...envp...) with envstrings with initial
On Tue, 22 Feb 2022 22:52:58 GMT, Roger Riggs wrote:
> fyi, the noreg-* labels apply to the bug report, not the PR. (and yes, they
> are informative when reviewing).
Thanks for pointing that out. I thought I may have been reading some old
documentation.
> One of
On Tue, 22 Feb 2022 17:20:25 GMT, Ichiroh Takiguchi
wrote:
>> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX.
>> The test was failed by:
>> Incorrect handling of envstrings containing NULs
>>
>> According to my investigation, this issue was happened after following
>> change was
path=...images/test/jdk/jtreg/native `. This change would be
> reasonable, but I prefer the approach taken in this PR.
>
> ### Testing
>
> This test now passes on my test machine running AIX 7.1.
Tyler Steele has updated the pull request incrementally with one additional
comm
This test had two failing sections on AIX related to an incorrect expected
value for LIBPATH. The two (previously failing) test sections are below.
- Test Runtime.exec(...envp...) with envstrings with initial `='
- Test Runtime.exec(...envp...) with envstrings containing NULs
This PR modifies
On Thu, 17 Feb 2022 22:50:37 GMT, Tyler Steele wrote:
> FileEncodingTest expects all non-Windows platforms will have
> `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set
> to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1.
>
> Ac
On Fri, 18 Feb 2022 20:54:24 GMT, Tyler Steele wrote:
>> FileEncodingTest expects all non-Windows platforms will have
>> `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set
>> to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1
On Fri, 18 Feb 2022 20:04:25 GMT, Naoto Sato wrote:
>> Tyler Steele has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Makes sm changes requested by Naoto
>
> test/jdk/java/lang/System/FileEncodingTest
ive.encoding
> with canonical names. As I am new to OpenJDK, I am especially looking to
> ensure that changing the value returned by native.encoding will not have
> unintended consequences elsewhere in the project.
Tyler Steele has updated the pull request incrementally with one additio
ive.encoding
> with canonical names. As I am new to OpenJDK, I am especially looking to
> ensure that changing the value returned by native.encoding will not have
> unintended consequences elsewhere in the project.
Tyler Steele has updated the pull request incrementally with one additi
On Fri, 18 Feb 2022 19:06:28 GMT, Tyler Steele wrote:
>> FileEncodingTest expects all non-Windows platforms will have
>> `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set
>> to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1
ive.encoding
> with canonical names. As I am new to OpenJDK, I am especially looking to
> ensure that changing the value returned by native.encoding will not have
> unintended consequences elsewhere in the project.
Tyler Steele has refreshed the contents of this pull request, and previou
ive.encoding
> with canonical names. As I am new to OpenJDK, I am especially looking to
> ensure that changing the value returned by native.encoding will not have
> unintended consequences elsewhere in the project.
Tyler Steele has updated the pull request incrementally with one additional
ive.encoding
> with canonical names. As I am new to OpenJDK, I am especially looking to
> ensure that changing the value returned by native.encoding will not have
> unintended consequences elsewhere in the project.
Tyler Steele has updated the pull request incrementally with one additional
ive.encoding
> with canonical names. As I am new to OpenJDK, I am especially looking to
> ensure that changing the value returned by native.encoding will not have
> unintended consequences elsewhere in the project.
Tyler Steele has refreshed the contents of this pull request, and previous
co
On Thu, 17 Feb 2022 22:50:37 GMT, Tyler Steele wrote:
> FileEncodingTest expects all non-Windows platforms will have
> `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set
> to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1.
>
> Ac
On Thu, 17 Feb 2022 22:50:37 GMT, Tyler Steele wrote:
> FileEncodingTest expects all non-Windows platforms will have
> `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set
> to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1.
>
> Ac
FileEncodingTest expects all non-Windows platforms will have
`Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to
COMPAT. This assumption does not hold for AIX where it is ISO-8859-1.
According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect
60 matches
Mail list logo
