On Wed, 27 Apr 2022 17:20:11 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has non ASCII character
>
>
On Tue, 26 Apr 2022 21:17:34 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has non ASCII character
>
> Thanks
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Ichiroh Takiguchi has updated the pull request
On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote:
> * Syntactically improves a few cases from 8285676
> (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not
> included in the API Documentation, are visible in and processed
Hello.
I found a few methods in MethodUtil class which seem unused to me:
getPublicMethods, getInterfaceMethods, getInternalPublicMethods ,addMethod.
Are they somehow used by VM, or is it just leftovers from some refactorings?
I wonder if we can drop them.
Andrey Turbanov
On Fri, 29 Apr 2022 08:15:32 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-424 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Fri, 29 Apr 2022 06:31:22 GMT, Andrey Turbanov wrote:
> `Map.containsKey` call is sometimes unnecessary, when it's known that Map
> doesn't contain `null` values.
> Instead we can just use Map.get and compare result with `null`.
> I found one of such place, where Map.containsKey calls could
On Sat, 23 Apr 2022 21:02:50 GMT, Andrey Turbanov wrote:
> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
> Compared via JMH benchmark: 150ns -> 125ns/op
>
> Benchamark adapted from
> http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java
>
>
>