On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing
> `test/jdk/java/util/LinkedHashMap/Basic.java`
Please review this PR.
SDK 10.15 and earlier reports os.version as 10.16 on Big Sur. This fix will
check if dynamic linker support, which is supported from Big Sur, is available
or not on the OS even if os.version is reported as 10.16 instead of 11. The
os.version 10.16 doesn't include the
On Wed, 8 Jun 2022 09:39:04 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using
>> the same approach as the JVM does for long and floating-point comparisons.
>> This allows efficient and reliable usage of unsigned comparison in
On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing
> `test/jdk/java/util/LinkedHashMap/Basic.java`
On Thu, 9 Jun 2022 07:35:43 GMT, Andrey Turbanov wrote:
> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
>
> Instead of separate Hashtable.get/remove calls we can just use value returned
> by
https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
Instead of separate Hashtable.get/remove calls we can just use value returned
by `remove`,
It results in cleaner and a bit faster code.
-
> Modify native multi-byte read-write code used by the `java.io` classes to
> limit the size of the allocated native buffer thereby decreasing off-heap
> memory footprint and increasing throughput.
Brian Burkhalter has updated the pull request with a new target base due to a
merge or a rebase.
On Thu, 9 Jun 2022 16:04:43 GMT, Claes Redestad wrote:
>> To take optimal advantage of the pre-existing optimization for repeated
>> filters we could split the application of different types of stringifiers.
>>
>> The resulting difference in order of evaluation is not observable by
>>
On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote:
> Time to start getting ready for JDK 20...
This pull request has now been integrated.
Changeset: edff51e5
Author:Joe Darcy
Committer: Erik Joelsson
URL:
https://git.openjdk.org/jdk/commit/edff51e5fdb5282830ecfb3792a88c7b28ca6557
> To take optimal advantage of the pre-existing optimization for repeated
> filters we could split the application of different types of stringifiers.
>
> The resulting difference in order of evaluation is not observable by
> conventional means since all reference type share the same object
>
On Tue, 7 Jun 2022 14:15:55 GMT, Gaurav Chaudhari wrote:
>> This fix ensures that when a lookup for a custom TZ code fails, and an
>> attempt is made to find the GMT offset in order to get the current time,
>> Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the
On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie wrote:
> The test
> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
> verifies different failure modes of resource bundles. One of the failures is
> that the runner class, `MissingResourceCauseTestRun.java`,
On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato wrote:
>> The test
>> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
>> verifies different failure modes of resource bundles. One of the failures is
>> that the runner class, `MissingResourceCauseTestRun.java`, creates a
My main concerns are about security, that many object details, while
useful to viewers, should not be accessible by any code under any
circumstances. Having any code able to print all field content of any
object sounds extremely dangerous.
In my opinion, we can use a MethodHandles.Lookup as a
On Tue, 7 Jun 2022 12:34:25 GMT, Claes Redestad wrote:
> - Reduce runtime by running fewer forks, fewer iterations, less warmup. All
> micros tested in this group appear to stabilize very quickly.
> - Refactor BigIntegers to avoid re-running some (most) micros over and over
> with parameter
On Tue, 7 Jun 2022 12:34:25 GMT, Claes Redestad wrote:
> - Reduce runtime by running fewer forks, fewer iterations, less warmup. All
> micros tested in this group appear to stabilize very quickly.
> - Refactor BigIntegers to avoid re-running some (most) micros over and over
> with parameter
> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved
> flags is used
Thiago Henrique Hüpner has updated the pull request incrementally with one
additional commit since the last revision:
Update author
-
Changes:
- all:
We still handle at a number of places ancient historic _MSC_VER versions of
Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
This should be cleaned up, as long as it is not 3rd party code that we don't
want to adjust.
Currently still supported ("valid") VS version are 2017+,
On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato wrote:
>> The test
>> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
>> verifies different failure modes of resource bundles. One of the failures is
>> that the runner class, `MissingResourceCauseTestRun.java`, creates a
19 matches
Mail list logo