/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?
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
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
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/
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
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
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/
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.
-
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()`.
>
>
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
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
> u
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
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
> u
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()`.
src/ja
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
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
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/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-
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
>
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] Repla
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 shorter a
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 shorter a
`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 String.contai
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
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 can
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 integrat
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: h
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:A
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 trackin
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/jd
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)
-
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
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: https://git.openjdk.java.net/jdk/pull/8487/files
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
>>
&
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
>>
&
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&pr=8715&range=00
Issue:
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
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
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.c
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 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.c
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)
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
`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 perf
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
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 = 5
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
-
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 the
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 c
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 sep
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
> 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
--
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: https:/
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
mentException();
}
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
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
col
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
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
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
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. In c
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
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&pr=8013&range=00
Issue: https://bugs.o
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`.
--
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 `ind
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 lines
> 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>
-
Chan
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
> 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/pu
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:
> 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.no
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&pr=7879&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8283426
ler/toolchains?
As I know, JDK now supports only recent versions of Visual Studio. (2017+).
Or this file should be compilable with older versions as well?
Andrey Turbanov
gration of 'JDK-8169069 Module system
implementation refresh (11/2016)' -
https://github.com/openjdk/jdk/commit/fbe85300bfcc69cb4dd56e4df33ceea632366283
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`
>
> Fi
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). Last
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). Last
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
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_
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
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&pr=7538&range=00
Issue: https://bugs.op
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
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
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] Remove
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
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 LineNumberInputStream
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
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% /
>
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% /
>
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
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
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. Shou
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
C
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% /
>
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
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();`.
--
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= 2998770
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 H
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.
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.
https://github.com/openjdk/jdk/blob/7b6738fa02023825ed9e602555bd5ed2b87a6ca6/src/ja
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:
o get a NPE here? Another thread could
change uncaughtExceptionHandler between 2 volatile reads.
Or JVM somehow forbid this?
Andrey Turbanov
1 - 100 of 352 matches
Mail list logo