> Can I please get a review for this change which fixes the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8275509?
>
> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
> components to compute the final hash code. While doing so it ends up calling
> hashC
> Can I please get a review for this change which fixes the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8275509?
>
> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
> components to compute the final hash code. While doing so it ends up calling
> hashC
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe` interfac
> Can I please get a review for this change which fixes the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8275509?
>
> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
> components to compute the final hash code. While doing so it ends up calling
> hashC
On 01/11/21 7:26 am, Jaikiran Pai wrote:
Hello Alan,
On 01/11/21 1:03 am, Alan Bateman wrote:
On Fri, 29 Oct 2021 04:19:21 GMT, Jaikiran Pai wrote:
Do you mean the jtreg `driver` style this test is using? I used it
because it was necessary to compare output (the hashCode value)
between mu
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe` interfac
> Can I please get a review for this change which fixes the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8275509?
>
> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
> components to compute the final hash code. While doing so it ends up calling
> hashC
Hello Alan,
On 01/11/21 1:03 am, Alan Bateman wrote:
On Fri, 29 Oct 2021 04:19:21 GMT, Jaikiran Pai wrote:
Do you mean the jtreg `driver` style this test is using? I used it because it
was necessary to compare output (the hashCode value) between multiple JVM runs.
I use the `driver` along w
On Fri, 29 Oct 2021 04:19:21 GMT, Jaikiran Pai wrote:
> Do you mean the jtreg `driver` style this test is using? I used it because it
> was necessary to compare output (the hashCode value) between multiple JVM
> runs. I use the `driver` along with the `ProcessBuilder` to capture the
> output b
Hi,
Since it seems that the mailing list is scrubbing attachments, patch is
mentioned inline below.
diff a/src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java
b/src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java
--- a/src/java.base/share/classes/jdk/internal/util/xm
Hi,
Properties.loadFromXML/storeToXML works incorrectly for supplementary
characters after JDK-8042889[1] was integrated in JDK 9.
Properties.storeToXML now generates incorrect character references for
supplementary characters. This is similar to JDK-8145974[2] which was fixed
in the java.xml mod
11 matches
Mail list logo
