Hi,
`Objects.requireNonNull` may fail to be inlined. The call is expensive and may
lead to objects escaping to the heap while the null check is cheap and is often
elided. I have observed this when using the vector API when a call to
`Objects.requireNonNull` leads to vectors being materialised
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.
>>
>> According to
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.
>>
>> According to
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.java line 2:
>
>> 1: /*
>> 2: *
> 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
On 2/18/22 3:42 AM, Eirik Bjørsnøs wrote:
Hi,
Currently, StackWalker.StackFrame::getByteCodeIndex provides a way to get
the BCI of stack frames during a stack walk.
Similarly, it might be useful to get the BCI when inspecting a Throwable's
StackTraceElements. This does however not seem
Hello,
to overcome some of the problems with parsing and generating Windows
command lines, I implemented two classes [1] that attempt to provide a
more sophisticated solution. To be clear, they do not create processes
or launch programs. They only serve as a parser and an "escaper".
On Fri, 18 Feb 2022 19:50:33 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.
>>
>> According to
> Hi all,
>
> Please review the attached patch to address
>
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
> parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
> unexpected exception occurs
>
> Mach5 tiers1-3 runs are clean
> 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
> Hi all,
>
> Please review the attached patch to address
>
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
> parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
> unexpected exception occurs
>
> Mach5 tiers1-3 runs are clean
On Fri, 18 Feb 2022 17:20:26 GMT, Alan Bateman wrote:
> > If you feel there is still something lacking for documentation, I can
> > certainly make another pass clarify/add it, but I tried to cover the steps
> > (but I also understand what might be obvious to me might not be as obvious
> > as
> Hi all,
>
> Please review the attached patch to address
>
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
> parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
> unexpected exception occurs
>
> Mach5 tiers1-3 runs are clean
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.
>>
>> According to
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.
>>
>> According to
On Fri, 18 Feb 2022 18:53:43 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> revert unrelated changes and add it to ProblemList.txt
> 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
On Fri, 18 Feb 2022 18:32:31 GMT, Stuart Marks wrote:
> Sigh. (I'm sighing at the author of the
> Enum/ConstantDirectoryOptimalCapacity.java test, not you.) What a mess. See
> https://bugs.openjdk.java.net/browse/JDK-8282120 which I just filed. The
> broken test and the OptimalCapacity
> 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
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
revert unrelated changes and add it to ProblemList.txt
https://bugs.openjdk.java.net/browse/JDK-8282120
> 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
> 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
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.
>
> According to
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.
>
> According to
On Fri, 18 Feb 2022 15:29:25 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - migrate to junit
> - change threshold
Sigh. (I'm
Hi Sverre,
Interesting, I don't see changes in jpackage code related to the issue.
In particular jdk.jpackage.internal.IOUtils.writableOutputDir() function
is the same in JDK14, JDK17, and mainline.
- Alexey
On 2/18/2022 8:31 AM, Sverre Moe wrote:
I executed our JDK11 docker image, which
On Fri, 18 Feb 2022 16:15:18 GMT, Roger Riggs wrote:
> I'm uncertain whether the fallback should only be done on Linux to cover the
> `systemd` case and Docker.
> The need for a fallback seems less applicable on macOs, but since $HOME is
> usually set to the same value, may be harmless.
I
On Thu, 17 Feb 2022 05:45:54 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix test
>
> OK, good progress. Yes, leaving ConcurrentHashMap to another PR is fine.
>
> Do the changes to Class.java
On Fri, 18 Feb 2022 14:53:42 GMT, Roger Riggs wrote:
> The Location enum does give more control over the places modifiers can occur
> and be extended as needed. But its unfortunate there's no (simple/obvious)
> mapping to the other concepts of the corresponding types, such as ElementType
> or
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.
>
> According to
On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova
wrote:
>> This fix made equal processing of strings such as ""C:\\Program
>> Files\\Git\\"" before and after JDK-8250568.
>>
>> For example, it's needed to execute the following command on Windows:
>> `C:\Windows\SysWOW64\WScript.exe
On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova
wrote:
>> This fix made equal processing of strings such as ""C:\\Program
>> Files\\Git\\"" before and after JDK-8250568.
>>
>> For example, it's needed to execute the following command on Windows:
>> `C:\Windows\SysWOW64\WScript.exe
On Fri, 18 Feb 2022 17:15:17 GMT, Lance Andersen wrote:
> If you feel there is still something lacking for documentation, I can
> certainly make another pass clarify/add it, but I tried to cover the steps
> (but I also understand what might be obvious to me might not be as obvious as
> I
> This fix made equal processing of strings such as ""C:\\Program
> Files\\Git\\"" before and after JDK-8250568.
>
> For example, it's needed to execute the following command on Windows:
> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"`
> it's equal to:
> `new
On Fri, 18 Feb 2022 17:05:53 GMT, Alan Bateman wrote:
> > > The updates changes to ZipFile/JarFile look okay. I don't have time to
> > > study the test too closely right now but it will need to include
> > > instructions on how to re-create the signed JAR that is stored in the
> > > byte
On Fri, 18 Feb 2022 16:25:30 GMT, Lance Andersen wrote:
> > The updates changes to ZipFile/JarFile look okay. I don't have time to
> > study the test too closely right now but it will need to include
> > instructions on how to re-create the signed JAR that is stored in the byte
> > array.
>
On Fri, 18 Feb 2022 16:07:29 GMT, Olga Mikhaltsova
wrote:
>> This fix made equal processing of strings such as ""C:\\Program
>> Files\\Git\\"" before and after JDK-8250568.
>>
>> For example, it's needed to execute the following command on Windows:
>> `C:\Windows\SysWOW64\WScript.exe
On Fri, 18 Feb 2022 12:09:53 GMT, Alan Bateman wrote:
> The updates changes to ZipFile/JarFile look okay. I don't have time to study
> the test too closely right now but it will need to include instructions on
> how to re-create the signed JAR that is stored in the byte array.
Those
On Fri, 18 Feb 2022 15:29:34 GMT, Roger Riggs wrote:
> In some Linux configurations, the Linux home directory provided by getpwent
> is not usable.
> The value of the system property `user.home` should fallback to the value of
> $HOME
> if getpwent.user_home is null or less that 2 characters
> This fix made equal processing of strings such as ""C:\\Program
> Files\\Git\\"" before and after JDK-8250568.
>
> For example, it's needed to execute the following command on Windows:
> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"`
> it's equal to:
> `new
> I'm requesting comments and, hopefully, some help with this patch to replace
> `StringCoding.hasNegatives` with `countPositives`. The new method does a very
> similar pass, but alters the intrinsic to return the number of leading bytes
> in the `byte[]` range which only has positive bytes.
On Fri, 18 Feb 2022 15:29:34 GMT, Roger Riggs wrote:
> In some Linux configurations, the Linux home directory provided by getpwent
> is not usable.
> The value of the system property `user.home` should fallback to the value of
> $HOME
> if getpwent.user_home is null or less that 2 characters
In some Linux configurations, the Linux home directory provided by getpwent is
not usable.
The value of the system property `user.home` should fallback to the value of
$HOME
if getpwent.user_home is null or less that 2 characters long. "/" is not a
valid home directory name.
If $HOME is
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with two additional
commits since the last revision:
- migrate to junit
- change threshold
-
Changes:
- all:
On Fri, 18 Feb 2022 11:20:12 GMT, XenoAmess wrote:
> well seems jtreg cannot invoke Junit4 's parameterized test.
Nope, it can! :)
-
PR: https://git.openjdk.java.net/jdk/pull/7431
On Fri, 18 Feb 2022 03:38:36 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On 18/02/2022 7:55 pm, Andrey Turbanov wrote:
Hello.
I noticed unused field java.math.MathContext#DEFAULT_DIGITS
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/math/MathContext.java#L61
As I can see, it was already unused in the initial OpenJDK source.
Does VM use
I executed our JDK11 docker image, which works fine with JDK11 and JDK14
(for jpackage support).
Then I installed the JDK17 MSI package, changed JAVA_HOME and PATH.
Building our application now with JDK17 it still cannot write to the
"build/native" jpackage output directory.
Leads me to conclude
On Thu, 17 Feb 2022 19:00:47 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the attached patch to address
>>
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
>> parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
Hi,
Currently, StackWalker.StackFrame::getByteCodeIndex provides a way to get
the BCI of stack frames during a stack walk.
Similarly, it might be useful to get the BCI when inspecting a Throwable's
StackTraceElements. This does however not seem possible, given that
StackTraceElement currently
On Thu, 17 Feb 2022 19:39:47 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> migrate to junit
well seems jtreg cannot invoke
Hello.
I noticed unused field java.math.MathContext#DEFAULT_DIGITS
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/math/MathContext.java#L61
As I can see, it was already unused in the initial OpenJDK source.
Does VM use this field somehow? Or used to use?
Andrey
On Thu, 17 Feb 2022 20:58:54 GMT, Lance Andersen wrote:
> The change looks innocuous so it is probably OK. I would like to kick of our
> Mach5 runs to see if it shakes out any potential issues.
>
Thanks Lance! Much appreciated.
> From reading the 3rd party problem reports, it appears that
- Original Message -
> From: "Stuart Marks"
> To: "Remi Forax"
> Cc: "core-libs-dev" , "Tagir Valeev"
>
> Sent: Tuesday, February 15, 2022 6:06:54 AM
> Subject: Re: [External] : Sequenced Collections
>> Here is the first sentence of the javadoc for java.util.List "An ordered
>>
54 matches
Mail list logo
