On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov
wrote:
> Usages of primitive types should be preferred and makes code easier to read.
> Similar cleanups:
> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168)
> java.desktop
> 2. [JDK-8274234](https://bugs.openjdk.java.net/browse
On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
> This reimplements core reflection with method handles.
>
> For `Constructor::newInstance` and `Method::invoke`, the new implementation
> uses `MethodHandle`. For `Field` accessor, the new implementation uses
> `VarHandle`.For the first few invocations of one of these reflective
> methods
> This reimplements core reflection with method handles.
>
> For `Constructor::newInstance` and `Method::invoke`, the new implementation
> uses `MethodHandle`. For `Field` accessor, the new implementation uses
> `VarHandle`.For the first few invocations of one of these reflective
> methods
On Fri, 8 Oct 2021 21:29:19 GMT, Maurizio Cimadamore
wrote:
>> Hi @mcimadamore,
>>
>> As you mentioned at
>> https://github.com/openjdk/jdk/pull/4316#issuecomment-853238872, the system
>> lookup is supported by the underlying `NativeLibraries` which also works on
>> OpenJDK16 to support `Lib
On Fri, 8 Oct 2021 04:43:08 GMT, Cheng Jin
wrote:
> So I am wondering what happened to the system lookup in such case given there
> should be no fundamental difference in leveraging `NativeLibraries` (I assume
> the library loading in OpenJDK16 & 17 is the same at this point) unless there
> i
On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
On Wed, 6 Oct 2021 18:08:04 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274544: Langtools command's usage were garbled on Japanese Windows
>
> I got your issue now. Since the current code
On Wed, 6 Oct 2021 18:08:04 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274544: Langtools command's usage were garbled on Japanese Windows
>
> I got your issue now. Since the current code
On Thu, 7 Oct 2021 18:00:33 GMT, Andrey Turbanov
wrote:
> Pass cause exception as constructor parameter is shorter and easier to read.
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5854
On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato wrote:
> While working on tzdata2021c update, I noticed there is a dead code in
> `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for
> `endOfDay` for certain cases. These are no longer needed as JDK's code is
> already capable of
On Fri, 8 Oct 2021 09:35:25 GMT, Daniel Fuchs wrote:
>Did you run tier1, tier2?
I did run tier2. (tier1 is automatically checked by GithubActions).
No new tests failed. Only _usual_ tests, which always fail on my machine, were
failed.
-
PR: https://git.openjdk.java.net/jdk/pull/55
On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov
wrote:
> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check
> if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to rea
On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov
wrote:
> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check
> if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to rea
On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov
wrote:
> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check
> if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to rea
String.contains was introduced in Java 5.
Some code in java.base still uses old approach with `String.indexOf` to check
if String contains specified substring.
I propose to migrate such usages. Makes code shorter and easier to read.
-
Commit messages:
- [PATCH] Use String.contains()
On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov
wrote:
> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check
> if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to rea
Pass cause exception as constructor parameter is shorter and easier to read.
-
Commit messages:
- [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.rmi module
Changes: https://git.openjdk.java.net/jdk/pull/5854/files
Webrev: https://webrevs.openjdk.java.net/?repo=j
On Wed, 6 Oct 2021 21:21:29 GMT, iaroslavski
wrote:
>> Sorting:
>>
>> - adopt radix sort for sequential and parallel sorts on
>> int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single
>> element
>> - minor javad
On Wed, 6 Oct 2021 21:21:29 GMT, iaroslavski
wrote:
>> Sorting:
>>
>> - adopt radix sort for sequential and parallel sorts on
>> int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single
>> element
>> - minor javad
On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato wrote:
> While working on tzdata2021c update, I noticed there is a dead code in
> `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for
> `endOfDay` for certain cases. These are no longer needed as JDK's code is
> already capable of
21 matches
Mail list logo
