Handling of USR2 signal in JVM on Linux

2022-06-14 Thread Andrey Turbanov
/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot? Andrey Turbanov

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]

2022-06-14 Thread Andrey Turbanov
On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken wrote: >> 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

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]

2022-06-13 Thread Andrey Turbanov
On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken wrote: >> 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

Re: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX [v2]

2022-06-13 Thread Andrey Turbanov
On Sun, 15 May 2022 10:31:20 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/

Re: RFR: 8287696: Avoid redundant Hashtable.containsKey call in JarVerifier.doneWithMeta

2022-06-11 Thread Andrey Turbanov
On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov wrote: > Hashtable doesn't allow `null` values. So, instead of pair > `containsKey`/`remove` calls, we can directly call `remove` and then compare > result with `null`. > https://github.com/open

Integrated: 8287696: Avoid redundant Hashtable.containsKey call in JarVerifier.doneWithMeta

2022-06-11 Thread Andrey Turbanov
On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov wrote: > Hashtable doesn't allow `null` values. So, instead of pair > `containsKey`/`remove` calls, we can directly call `remove` and then compare > result with `null`. > https://github.com/open

Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle [v2]

2022-06-10 Thread Andrey Turbanov
bit faster code. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8288140: Avoid redundant Hashtable.get call in Signal.handle apply dmlloyd's suggestion - Changes: - all: https://git.openjdk.org/jdk/pull/9100/files

RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle

2022-06-09 Thread Andrey Turbanov
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. -

Re: RFR: 8287541: Files.writeString fails to throw IOException for charset "windows-1252" [v2]

2022-06-07 Thread Andrey Turbanov
On Mon, 6 Jun 2022 15:50:39 GMT, Naoto Sato wrote: >> The code path calls `String.getBytesNoRepl()`, but it blindly replaces >> unmappable characters with replacements if the encoder is an `ArrayEncoder`. >> Changed only to do so if `doReplace` is `true` in >> `String.encodeWithEncoder()`. >

Integrated: 8285285: Avoid redundant allocations in WindowsPreferences

2022-06-06 Thread Andrey Turbanov
On Wed, 20 Apr 2022 19:16:00 GMT, Andrey Turbanov wrote: > 1. No need to call `String.substring` if you need need to compare start of > string with some constant. `String.startWith` suites better. > 2. Unused String array is allocated in `childrenNamesSpi` method This pull request has

Integrated: 8287766: Unnecessary Vector usage in LdapClient

2022-06-06 Thread Andrey Turbanov
On Sun, 29 May 2022 20:22:55 GMT, Andrey Turbanov wrote: > In [JDK-8273098](https://bugs.openjdk.java.net/browse/JDK-8273098) I missed > one place, where Vector could be replaced with ArrayList. > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to > us

Re: RFR: 8285285: Avoid redundant allocations in WindowsPreferences

2022-06-06 Thread Andrey Turbanov
On Wed, 20 Apr 2022 19:16:00 GMT, Andrey Turbanov wrote: > 1. No need to call `String.substring` if you need need to compare start of > string with some constant. `String.startWith` suites better. > 2. Unused String array is allocated in `childrenNamesSpi` method Thank you f

Re: RFR: 8287766: Unnecessary Vector usage in LdapClient

2022-06-06 Thread Andrey Turbanov
On Sun, 29 May 2022 20:22:55 GMT, Andrey Turbanov wrote: > In [JDK-8273098](https://bugs.openjdk.java.net/browse/JDK-8273098) I missed > one place, where Vector could be replaced with ArrayList. > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to > us

Re: RFR: 8287541: Files.writeString fails to throw IOException for charset "windows-1252"

2022-06-04 Thread Andrey Turbanov
On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato wrote: > The code path calls `String.getBytesNoRepl()`, but it blindly replaces > unmappable characters with replacements if the encoder is an `ArrayEncoder`. > Changed only to do so if `doReplace` is `true` in > `String.encodeWithEncoder()`.

Re: RFR: 8285285: Avoid redundant allocations in WindowsPreferences

2022-06-03 Thread Andrey Turbanov
On Wed, 20 Apr 2022 19:16:00 GMT, Andrey Turbanov wrote: > 1. No need to call `String.substring` if you need need to compare start of > string with some constant. `String.startWith` suites better. > 2. Unused String array is allocated in `childrenNamesSpi` method I believe it's prett

RFR: 8287766: Unnecessary Vector usage in LdapClient

2022-06-03 Thread Andrey Turbanov
In [JDK-8273098](https://bugs.openjdk.java.net/browse/JDK-8273098) I missed one place, where Vector could be replaced with ArrayList. Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. - Commit

RFR: 8287696: Avoid redundant Hashtable.containsKey call in JarVerifier.doneWithMeta

2022-06-01 Thread Andrey Turbanov
Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.

Integrated: 8287544: Replace uses of StringBuffer with StringBuilder in java.naming

2022-05-31 Thread Andrey Turbanov
On Sun, 29 May 2022 21:57:46 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. StringBuilder is a direct > replacement to StringBuffer which generally have better performance. > There are some code that still uses StringBuffer in java.naming which could >

RFR: 8287544: Replace uses of StringBuffer with StringBuilder in java.naming

2022-05-31 Thread Andrey Turbanov
StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance. There are some code that still uses StringBuffer in java.naming which could be migrated to `StringBuilder`. - Commit messages: - [PATCH]

Integrated: 8287497: Use String.contains() instead of String.indexOf() in java.naming

2022-05-31 Thread Andrey Turbanov
On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov wrote: > `String.contains` was introduced in Java 5. > Some code in java.naming still uses old approach with `String.indexOf` to > check if String contains specified substring. > I propose to migrate such usages. Makes code shorte

Re: RFR: 8287497: Use String.contains() instead of String.indexOf() in java.naming

2022-05-31 Thread Andrey Turbanov
On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov wrote: > `String.contains` was introduced in Java 5. > Some code in java.naming still uses old approach with `String.indexOf` to > check if String contains specified substring. > I propose to migrate such usages. Makes code shorte

RFR: 8287497: Use String.contains() instead of String.indexOf() in java.naming

2022-05-29 Thread Andrey Turbanov
`String.contains` was introduced in Java 5. Some code in java.naming 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

Integrated: 8287285: Avoid redundant HashMap.containsKey call in java.util.zip.ZipFile.Source.get

2022-05-26 Thread Andrey Turbanov
On Sat, 30 Apr 2022 08:56:23 GMT, Andrey Turbanov wrote: > The method `java.util.zip.ZipFile.Source#get` could be improved by usage of > `Map.putIfAbsent` instead of separate `containsKey`/`get`/`put` calls. We > known that HashMap `java.util.zip.ZipFile.Source#files` can contain on

RFR: 8287285: Avoid redundant HashMap.containsKey call in java.util.zip.ZipFile.Source.get

2022-05-25 Thread Andrey Turbanov
The method `java.util.zip.ZipFile.Source#get` could be improved by usage of `Map.putIfAbsent` instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `java.util.zip.ZipFile.Source#files` can contain only non-null values. And to check if putIfAbsent was successful or not we

Integrated: 8287181: Avoid redundant HashMap.containsKey calls in InternalLocaleBuilder.setExtension

2022-05-25 Thread Andrey Turbanov
On Sat, 30 Apr 2022 17:10:55 GMT, Andrey Turbanov wrote: > No need to separately perform `HashMap.containsKey` before `HashMap.remove` > call. If key is present - it will be removed anyway. If it's not present, > nothing will be deleted. This pull request has now been integrated.

RFR: 8287181: Avoid redundant HashMap.containsKey calls in InternalLocaleBuilder.setExtension

2022-05-23 Thread Andrey Turbanov
No need to separately perform `HashMap.containsKey` before `HashMap.remove` call. If key is present - it will be removed anyway. If it's not present, nothing will be deleted. - Commit messages: - [PATCH] Avoid redundant HashMap.containsKey calls in InternalLocaleBuilder Changes:

Integrated: 8287053: Avoid redundant HashMap.containsKey calls in ZoneInfoFile.getZoneInfo0

2022-05-23 Thread Andrey Turbanov
On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov wrote: > Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use > single call `HashMap.getOrDefault`. > It's faster and clearer. This pull request has now been integrated. Changeset: 01916e19 Author: Andrey

Re: RFR: 8284493: Fix rounding error in computeNextExponential

2022-05-22 Thread Andrey Turbanov
On Wed, 6 Apr 2022 17:47:53 GMT, Chris Hennick wrote: > Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a > rounding error to accumulate at the tail of the distribution (probably > starting around 2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1); this fixes > that by

Integrated: 8286858: Remove dead code in sun.reflect.misc.MethodUtil

2022-05-20 Thread Andrey Turbanov
On Sun, 15 May 2022 12:47:10 GMT, Andrey Turbanov wrote: > They are unused and leftover since JDK 7. It's good to remove them. This pull request has now been integrated. Changeset: 4587337e Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/com

Re: RFR: 8286858: Remove dead code in sun.reflect.misc.MethodUtil

2022-05-20 Thread Andrey Turbanov
On Wed, 18 May 2022 02:03:34 GMT, Mandy Chung wrote: >Do you know why there are test failures (they look unrelated)? All failed tests seems Loom-integration related. They fail only x86. Seems they are fixed in master under [JDK-8286476 ](https://bugs.openjdk.java.net/browse/JDK-8286476)

Integrated: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable

2022-05-19 Thread Andrey Turbanov
On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov wrote: > Method `Class.isAssignableFrom` is often used in form of: > > if (clazz.isAssignableFrom(obj.getClass())) { > Such condition could be simplified to more shorter and performarnt code > > if (cl

RFR: 8287053: Avoid redundant HashMap.containsKey calls in ZoneInfoFile.getZoneInfo0

2022-05-19 Thread Andrey Turbanov
Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`. It's faster and clearer. - Commit messages: - [PATCH] Avoid redundant HashMap.containsKey calls in ZoneInfoFile Changes:

Re: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2]

2022-05-19 Thread Andrey Turbanov
On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov wrote: >> Method `Class.isAssignableFrom` is often used in form of: >> >> if (clazz.isAssignableFrom(obj.getClass())) { >> Such condition could be simplified to more shorter and performarnt code >> &

Re: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2]

2022-05-17 Thread Andrey Turbanov
On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov wrote: >> Method `Class.isAssignableFrom` is often used in form of: >> >> if (clazz.isAssignableFrom(obj.getClass())) { >> Such condition could be simplified to more shorter and performarnt code >> &

RFR: 8286858: Remove dead code in sun.reflect.misc.MethodUtil

2022-05-17 Thread Andrey Turbanov
They are unused and leftover since JDK 7. It's good to remove them. - Commit messages: - [PATCH] Remove unused code in sun.reflect.misc.MethodUtil Changes: https://git.openjdk.java.net/jdk/pull/8715/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8715=00 Issue:

Re: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX [v2]

2022-05-15 Thread Andrey Turbanov
ch.value_toNanos 0 avgt5 121,556 ± 25,745 ns/op > TimeUnitBench.value_toNanos 1 avgt5 123,410 ± 22,323 ns/op > TimeUnitBench.value_toNanos 2 avgt5 125,452 ± 26,575 ns/op > TimeUnitBench.value_toNanos 3 avgt5 125,297 ± 26,204 ns/op > TimeU

Re: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2]

2022-05-10 Thread Andrey Turbanov
On Tue, 10 May 2022 11:10:50 GMT, Daniel Fuchs wrote: >> Andrey Turbanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8280035: Use Class.isInstance instead of Class.isAssignableFrom where >> applicable

Integrated: 8285947: Avoid redundant HashMap.containsKey calls in ZoneName

2022-05-05 Thread Andrey Turbanov
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

Unused method sun.reflect.misc.MethodUtil.getPublicMethods

2022-04-30 Thread Andrey Turbanov
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

Re: RFR: 8285947: Avoid redundant HashMap.containsKey calls in ZoneName

2022-04-29 Thread Andrey Turbanov
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

Re: RFR: 8285947: Avoid redundant HashMap.containsKey calls in ZoneName

2022-04-29 Thread Andrey Turbanov
On Fri, 29 Apr 2022 20:45:20 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/time/format/ZoneName.java.template line 60: >> >>> 58: >>> 59: public static String toZid(String zid) { >>> 60: return aliases.getOrDefault(zid, zid)

Re: RFR: 8285947: Avoid redundant HashMap.containsKey calls in ZoneName

2022-04-29 Thread Andrey Turbanov
On Fri, 29 Apr 2022 20:36:59 GMT, Roger Riggs wrote: >aliases.getOrDefault will throw NPE on null No, It will not. `aliases` is a HashMap. And HashMap supports null values and keys. - PR: https://git.openjdk.java.net/jdk/pull/8463

RFR: 8285947: Avoid redundant HashMap.containsKey calls in ZoneName

2022-04-29 Thread Andrey Turbanov
`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 be eliminated - `java.time.format.ZoneName`. it gives a bit of

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5]

2022-04-28 Thread Andrey Turbanov
On Thu, 28 Apr 2022 18:05:39 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), >> please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated >> out

RFR: 8285519: Simplify TimeUnit.convert calls

2022-04-24 Thread Andrey Turbanov
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 @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Measurement(iterations =

RFR: 8285285: Avoid redundant allocations in WindowsPreferences

2022-04-20 Thread Andrey Turbanov
1. No need to call `String.substring` if you need need to compare start of string with some constant. `String.startWith` suites better. 2. Unused String array is allocated in `childrenNamesSpi` method - Commit messages: - [PATCH] Avoid redundant allocations in WindowsPreferences -

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]

2022-04-15 Thread Andrey Turbanov
On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in

Re: RFR: 8284893: Fix typos in java.base

2022-04-15 Thread Andrey Turbanov
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those > changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in

Re: RFR: 8284853: Fix various 'expected' typo [v2]

2022-04-14 Thread Andrey Turbanov
On Thu, 14 Apr 2022 10:38:33 GMT, Yi Yang wrote: >I found [yet another >typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), > I wonder if you can merge this into your patch so that I do not need to >submit a new PR for it? Thanks. I think it deserves a

Integrated: 8284853: Fix various 'expected' typo

2022-04-14 Thread Andrey Turbanov
On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, > `expeced`, `Unexpeted`, etc. This pull request has now been integrated. Changeset: 48c75498 Author:Andrey Turbanov URL: https://git.openjdk.java.n

Re: RFR: 8284853: Fix various 'expected' typo [v2]

2022-04-14 Thread Andrey Turbanov
> Found various typos of expected: `exepected`, `exept`, `epectedly`, > `expeced`, `Unexpeted`, etc. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8284853: Fix various 'expected' typo improve test log - C

RFR: 8284853: Fix varios 'expected' typo

2022-04-13 Thread Andrey Turbanov
Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. - Commit messages: - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo Changes: https://git.openjdk.java.net/jdk/pull/8231/files Webrev:

Integrated: 8284567: Collapse identical catch branches in java.base

2022-04-11 Thread Andrey Turbanov
On Sat, 2 Apr 2022 16:05:06 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple > Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' > sta

Always false condition in 'java.nio.file.FileSystem#getPathMatcher implementations

2022-04-08 Thread Andrey Turbanov
ion(); } Variable 'pos' is the result of the 'String.indexOf' method call. Then variable 'pos' is compared with 'length()' of the string with ==. But the maximum possible returned value of String.indexOf() is 'length()-1'. It means check 'pos == syntaxAndInput.length()' will always be 'false'. Andrey Turbanov

RFR: 8284567: Collapse identical catch branches in java.base

2022-04-08 Thread Andrey Turbanov
Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". It simplifies code. Reduces duplication. Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement - Commit messages: - Merge remote-tracking branch 'origin/master' into

Unused sun.nio.fs.Reflect

2022-04-02 Thread Andrey Turbanov
Hello. As I can see, the class 'sun.nio.fs.Reflect' is unused in JDK java code. Is it somehow used by VM, or is it just leftovers from some refactorings? I wonder if we can drop it. Andrey Turbanov

Integrated: 8283801: Cleanup confusing String.toString calls

2022-03-30 Thread Andrey Turbanov
On Sun, 20 Mar 2022 13:20:31 GMT, Andrey Turbanov wrote: > String.toString() calls doesn't make much sense. Only one place, where it > could be used - to generate NPE. But in a few places of JDK codebase it's > called, even when NPE will happen anyway. > I propose to cleanup

Re: RFR: 8283801: Cleanup confusing String.toString calls

2022-03-30 Thread Andrey Turbanov
On Sun, 20 Mar 2022 13:20:31 GMT, Andrey Turbanov wrote: > String.toString() calls doesn't make much sense. Only one place, where it > could be used - to generate NPE. But in a few places of JDK codebase it's > called, even when NPE will happen anyway. > I propose to cleanup

Integrated: 8283800: Simplify String.indexOf/lastIndexOf calls

2022-03-30 Thread Andrey Turbanov
On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote: > In a few places String.indexOf/lastIndexOf methods are called with default > parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. > I propose to cleanup such calls. It makes code a bit easier to read

Integrated: 8283846: Remove unused jdk.internal.reflect.SignatureIterator

2022-03-30 Thread Andrey Turbanov
On Tue, 29 Mar 2022 09:15:01 GMT, Andrey Turbanov wrote: > It was no longer used due to JDK-4479184 long ago. This pull request has now been integrated. Changeset: b323f54f Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/b323f54feef13a47bb02af608eb1f6474692d

RFR: 8283846: Remove unused jdk.internal.reflect.SignatureIterator

2022-03-29 Thread Andrey Turbanov
It was no longer used due to JDK-4479184 long ago. - Commit messages: - [PATCH] Remove unused jdk.internal.reflect.SignatureIterator Changes: https://git.openjdk.java.net/jdk/pull/8013/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8013=00 Issue:

RFR: 8283801: Cleanup confusing String.toString calls

2022-03-28 Thread Andrey Turbanov
String.toString() calls doesn't make much sense. Only one place, where it could be used - to generate NPE. But in a few places of JDK codebase it's called, even when NPE will happen anyway. I propose to cleanup such places. Found by IntelliJ IDEA inspection `Redundant 'String' operation`.

RFR: 8283800: Simplify String.indexOf/lastIndexOf calls

2022-03-28 Thread Andrey Turbanov
In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for

Integrated: 8283426: Fix 'exeption' typo

2022-03-24 Thread Andrey Turbanov
On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` This pull request has now been integrated. Changeset: dc5a65ab Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/dc5a65ab378f0780f7760965f2b52cbbd7c62aad Stats: 38 li

Re: RFR: 8283426: Fix 'exeption' typo [v4]

2022-03-23 Thread Andrey Turbanov
> Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo Co-authored-by: Alexey Ivanov <70774172+aivanov-...@users.noreply.github.com> - Changes: - a

Unused class jdk.internal.reflect.SignatureIterator

2022-03-23 Thread Andrey Turbanov
Hello. As I can see, the class 'jdk.internal.reflect.SignatureIterator' is unused in JDK java code. Is it somehow used by VM, or is it just leftovers from some refactorings? I wonder if we can drop it. Andrey Turbanov

Re: RFR: 8283426: Fix 'exeption' typo [v3]

2022-03-23 Thread Andrey Turbanov
> Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo fix more typos, found by Sean Coffey - Changes: - all: https://git.openjdk.java.net/jdk/pull/7879/fi

Re: Unused paramter 'boolean newln' in java.lang.VersionProps#print(boolean err, boolean newln)

2022-03-22 Thread Andrey Turbanov
I mean _inside method body_ itself.It's only declared, but no code in the method refers to this parameter. Andrey Turbanov вт, 22 мар. 2022 г. в 01:37, Mandy Chung : > > VersionProps::print(boolean err, boolean newln) is called by > VersionProps::println(boolean) and VersionProps::prin

Re: RFR: 8283426: Fix 'exeption' typo [v2]

2022-03-21 Thread Andrey Turbanov
> Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo Apply suggestion Co-authored-by: Alexey Ivanov <70774172+aivanov-...@users.noreply.gith

RFR: 8283426: Fix 'exeption' typo

2022-03-20 Thread Andrey Turbanov
Fix repeated type `exeption` - Commit messages: - [PATCH] Typo 'Exeption' instead of 'Exception' Changes: https://git.openjdk.java.net/jdk/pull/7879/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7879=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283426 Stats:

Visual Studio 2005/2008 code in 'src/java.base/share/native/launcher/main.c'

2022-03-19 Thread Andrey Turbanov
know, JDK now supports only recent versions of Visual Studio. (2017+). Or this file should be compilable with older versions as well? Andrey Turbanov

Unused paramter 'boolean newln' in java.lang.VersionProps#print(boolean err, boolean newln)

2022-03-19 Thread Andrey Turbanov
-8169069 Module system implementation refresh (11/2016)' - https://github.com/openjdk/jdk/commit/fbe85300bfcc69cb4dd56e4df33ceea632366283 Andrey Turbanov

Re: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3]

2022-03-06 Thread Andrey Turbanov
On Sun, 6 Mar 2022 17:24:23 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/io/InvalidObjectException.java line 62: >> >>> 60: * @since 19 >>> 61: */ >>> 62: public InvalidObjectException(String reason, Throwable cause) { >> >> strange double space after `public` > >

Re: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3]

2022-03-06 Thread Andrey Turbanov
On Sat, 5 Mar 2022 03:29:44 GMT, Joe Darcy wrote: >> Occasionally in core-libs we've discussed whether or not to do a pass over >> the exception classes and proactively add any of four missing convention >> constructors per java.lang.Throwable (no-arg, string, cause, cause and >> string).

Re: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3]

2022-03-05 Thread Andrey Turbanov
On Sat, 5 Mar 2022 03:29:44 GMT, Joe Darcy wrote: >> Occasionally in core-libs we've discussed whether or not to do a pass over >> the exception classes and proactively add any of four missing convention >> constructors per java.lang.Throwable (no-arg, string, cause, cause and >> string).

Integrated: 8282188: Unused static field MathContext.DEFAULT_DIGITS

2022-02-24 Thread Andrey Turbanov
On Fri, 18 Feb 2022 19:07:15 GMT, Andrey Turbanov wrote: > 8282188: Unused static field MathContext.DEFAULT_DIGITS This pull request has now been integrated. Changeset: 3cfffa4f Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/com

Re: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable

2022-02-21 Thread Andrey Turbanov
On Thu, 20 Jan 2022 01:34:20 GMT, Phil Race wrote: >In short I see insufficient value in the changes here and would prefer you >drop the client part so I don't have to worry about it. I think, usage of `isInstance` is much clear for most java developers. Everyone knows about java _instanceof_

Re: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable

2022-02-21 Thread Andrey Turbanov
On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov wrote: > Method `Class.isAssignableFrom` is often used in form of: > > if (clazz.isAssignableFrom(obj.getClass())) { > Such condition could be simplified to more shorter and performarnt code > > if (cl

RFR: 8282188: Unused static field MathContext.DEFAULT_DIGITS

2022-02-21 Thread Andrey Turbanov
8282188: Unused static field MathContext.DEFAULT_DIGITS - Commit messages: - [PATCH] Remove unused field MathContext.DEFAULT_DIGITS Changes: https://git.openjdk.java.net/jdk/pull/7538/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7538=00 Issue:

Unused static constant MathContext.DEFAULT_DIGITS

2022-02-18 Thread Andrey Turbanov
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

Integrated: 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath

2022-02-17 Thread Andrey Turbanov
On Wed, 16 Feb 2022 14:48:04 GMT, Andrey Turbanov wrote: > Couple of fields in StrictMath are unused since > [JDK-8244146](https://bugs.openjdk.java.net/browse/JDK-8244146). > Also I fixed incorrect javadoc for private method. Looks like typo in > [JDK-6282196](https://bugs.open

RFR: 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath

2022-02-16 Thread Andrey Turbanov
Couple of fields in StrictMath are unused since [JDK-8244146](https://bugs.openjdk.java.net/browse/JDK-8244146). Also I fixed incorrect javadoc for private method. Looks like typo in [JDK-6282196](https://bugs.openjdk.java.net/browse/JDK-6282196) - Commit messages: - [PATCH]

Integrated: 8281728: Redundant null check in LineNumberInputStream.read

2022-02-14 Thread Andrey Turbanov
On Wed, 9 Feb 2022 18:51:22 GMT, Andrey Turbanov wrote: > At start of method `b` is already checked for null. > > https://github.com/openjdk/jdk/blob/178b962e01cc6c150442bf41dc6bd199caff0042/src/java.base/share/classes/java/io/LineNumberInputStream.java#L129-L131 > > Found b

RFR: 8281728: Redundant null check in LineNumberInputStream.read

2022-02-14 Thread Andrey Turbanov
At start of method `b` is already checked for null. https://github.com/openjdk/jdk/blob/178b962e01cc6c150442bf41dc6bd199caff0042/src/java.base/share/classes/java/io/LineNumberInputStream.java#L129-L131 - Commit messages: - [PATCH] Remove redundant null check in

Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v6]

2022-02-09 Thread Andrey Turbanov
On Tue, 8 Feb 2022 22:11:34 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 >> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was >> a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about

Integrated: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives.

2022-01-27 Thread Andrey Turbanov
On Thu, 20 Jan 2022 21:10:39 GMT, Andrey Turbanov wrote: > Test `test/java/io/File/GetXSpace.java` always failed on my machine with this > output: > > --System.out:(12/489)-- > --- Testing df > C:/Programs/cygwin64 292848636 49695320 243153316 17% / >

Re: RFR: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives.

2022-01-27 Thread Andrey Turbanov
On Thu, 20 Jan 2022 21:10:39 GMT, Andrey Turbanov wrote: > Test `test/java/io/File/GetXSpace.java` always failed on my machine with this > output: > > --System.out:(12/489)-- > --- Testing df > C:/Programs/cygwin64 292848636 49695320 243153316 17% / >

Integrated: 8280531: Remove unused DeferredCloseInputStream

2022-01-25 Thread Andrey Turbanov
On Tue, 18 Jan 2022 20:51:06 GMT, Andrey Turbanov wrote: > Class DeferredCloseInputStream is unused since removing of Solaris support > https://github.com/openjdk/jdk/blob/9fe4b69c1a1120e1d761730495c3cfac8f179d13/src/java.base/unix/classes/java/lang/ProcessImpl.java#L80-L81 This pull r

Integrated: 8280470: Confusing instanceof check in HijrahChronology.range

2022-01-25 Thread Andrey Turbanov
On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote: > Parameter `ChronoField field` is checked by `if (field instanceof > ChronoField)`. Such check is confusing, because only one case, when this > could be `false` is when `field == null`. > But if condition is not satisfied

Re: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match

2022-01-24 Thread Andrey Turbanov
On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote: > Replacing a buggy NullPointerException in `Pattern.compile()` with the proper > PatternSyntaxException test/jdk/java/util/regex/RegExTest.java line 4551: > 4549: } > 4550: > 4551: //This test is for This comment is confusing.

RFR: 8280531: Remove unused DeferredCloseInputStream

2022-01-24 Thread Andrey Turbanov
Class DeferredCloseInputStream is unused since removing of Solaris support https://github.com/openjdk/jdk/blob/9fe4b69c1a1120e1d761730495c3cfac8f179d13/src/java.base/unix/classes/java/lang/ProcessImpl.java#L80-L81 - Commit messages: - [PATCH] Remove unused DeferredCloseInputStream

Re: RFR: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives.

2022-01-24 Thread Andrey Turbanov
On Thu, 20 Jan 2022 21:10:39 GMT, Andrey Turbanov wrote: > Test `test/java/io/File/GetXSpace.java` always failed on my machine with this > output: > > --System.out:(12/489)-- > --- Testing df > C:/Programs/cygwin64 292848636 49695320 243153316 17% / >

Integrated: 8280174: Possible NPE in Thread.dispatchUncaughtException

2022-01-24 Thread Andrey Turbanov
On Mon, 17 Jan 2022 20:56:56 GMT, Andrey Turbanov wrote: > Method `Thread.dispatchUncaughtException` (called by VM) uses result of of > `getUncaughtExceptionHandler`. Field `uncaughtExceptionHandler` is volatile > and can be changed by another Thread. Which could lead to NPE

RFR: 8280470: Confusing instanceof check in HijrahChronology.range

2022-01-21 Thread Andrey Turbanov
Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`. But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`.

RFR: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives.

2022-01-20 Thread Andrey Turbanov
Test `test/java/io/File/GetXSpace.java` always failed on my machine with this output: --System.out:(12/489)-- --- Testing df C:/Programs/cygwin64 292848636 49695320 243153316 17% / D: 59672 59672 0 100% /cygdrive/d SecurityManager = null C:/Programs/cygwin64: df total=

Integrated: 8277535: Remove redundant Stream.distinct()/sorted() steps

2022-01-20 Thread Andrey Turbanov
On Mon, 27 Sep 2021 11:20:53 GMT, Andrey Turbanov wrote: > 1. Stream.distinct() is redundant before toSet() collector. Duplicates will > be collapsed by Collector. > 2. Stream.sorted() is redundant before toMap() collector. Keys will be > shuffled by Collector (it's a HashMa

Integrated: 8274811: Remove superfluous use of boxing in java.base

2022-01-19 Thread Andrey Turbanov
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.

RFR: 8280174: Possible NPE in Thread.dispatchUncaughtException

2022-01-18 Thread Andrey Turbanov
Method `Thread.dispatchUncaughtException` (called by VM) uses result of of `getUncaughtExceptionHandler`. Field `uncaughtExceptionHandler` is volatile and can be changed by another Thread. Which could lead to NPE.

Integrated: 8280010: Remove double buffering of InputStream for Properties.load

2022-01-18 Thread Andrey Turbanov
On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already > buffers input stream. Hence wrapping InputStream in BufferedInputStream is > redundant. This pull request has now been integrated. Changeset:

Thread.dispatchUncaughtException possible NPE?

2022-01-17 Thread Andrey Turbanov
a NPE here? Another thread could change uncaughtExceptionHandler between 2 volatile reads. Or JVM somehow forbid this? Andrey Turbanov

  1   2   3   >