Hello!
I read source code equalsIgnoreCase(...) in String class and saw that it is not
optimal. This method check length and call regionMatches(...) with 'constant'
values
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/lang/String.java#l1095
...
&& (a
26/2016 03:25 PM, Andrey wrote:
>> May be can create optimized regionMatches(...) for use in
>> equalsIgnoreCase(...)?
>
> When the HotSpot JVM's just-in-time compiler optimizes this code it
> inlines all of these tests, realizes that they are constant values,
>
I publish my JMH benchmark at github
https://github.com/volodin-aa/openjdk-benchmark
27.04.2016, 01:23, "Andrey" :
> I create simple benchmark (attached). Optimized version more faster:
>
> # JMH 1.12 (released 26 days ago)
> # VM version: JDK 1.8.0_91, VM 25.91-b14
> .
hm has performance as standard
String.equalsIgnoreCase(...) .
27.04.2016, 13:17, "Andrew Haley" :
> On 27/04/16 10:57, Andrey wrote:
>
>> I publish my JMH benchmark at github
>> https://github.com/volodin-aa/openjdk-benchmark
>
> This test needs to be better
ring" and "String" my version more faster then internalVM version.
In other cases VM optimization is faster.
27.04.2016, 14:38, "Aleksey Shipilev" :
> Hi Andrey,
>
> On 04/27/2016 12:57 PM, Andrey wrote:
>> I publish my JMH benchmark at github
>>
to subclass AbstractObjectInputStream.
+ * only trusted classes are allowed to subclass AbstractObjectOutputStream.
* Subclasses of AbstractObjectOututStream must have SerializablePermission
* "enableAbstractSubclass" or this constructor will throw a
* SecurityException.Implementations
; lack permissions to write
files inside "Program File/MyApp".
--
Best regards,
Andrey Volkov
Hello.
Can you give a hint or en example how to use --resource-dir option for
jpackage?
According to the help, it is possible to override jpackage's resources
(icons, logos, etc. that are shown in installers). Is it right?
--
Best regards,
Andrey Volkov
6882207: Convert javap to use diamond operator internally
-
Commit messages:
- 6882207: Convert javap to use diamond operator internally
Changes: https://git.openjdk.java.net/jdk/pull/1677/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1677&range=00
Issue: https://bu
On Mon, 7 Dec 2020 20:30:07 GMT, Andrey Turbanov
wrote:
> 6882207: Convert javap to use diamond operator internally
This pull request has now been integrated.
Changeset: 30de320c
Author: Andrey Turbanov
Committer: Jonathan Gibbons
URL: https://git.openjdk.java.net/jdk/com
On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov
wrote:
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
I believe this changes is useful and still actual:
1. improve code to make it easier to read.
2. performance should be improved a b
8258422: Cleanup unnecessary null comparison before instanceof check in
java.base
-
Commit messages:
- [PATCH] Cleanup unnecessary null comparison before instanceof check in
java.base
Changes: https://git.openjdk.java.net/jdk/pull/20/files
Webrev: https://webrevs.openjdk.java.net
On Mon, 2 Nov 2020 09:15:31 GMT, Chris Hegarty wrote:
>> I’ll see if I can get somebody to take a look at this.
>
> This seems like a reasonable change, which improves readability.
>
> My preference is to wait a little longer (hopefully no more than a couple of
> weeks), until [JEP 394](https:/
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Andrey Turbanov has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request co
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8258422: Cleanup unnecessary null comparison before instanceof check in
java.base
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8258422: Cleanup unnecessary null comparison before instanceof check in
java.base
On Wed, 16 Dec 2020 18:27:35 GMT, Aleksei Efimov wrote:
>> Let's take advantage of "flow scoping" to eliminate some of these casts. A
>> few examples follow.
>
> Hi Andrey,
>
> Could you, please, also take a look at `java.net.Socket`:
> java/net
On Thu, 17 Dec 2020 10:29:50 GMT, Alan Bateman wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.bas
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8258422: Cleanup unnecessary null comparison before instanceof check in
jav
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8258422: Cleanup unnecessary null comparison before instanceof check in
java.base
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8258422: Cleanup unnecessary null comparison before instanceof check in
java.base
8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
-
Commit messages:
- 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
- 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
Changes: https://git.openjdk.java.
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
revert changes in JrtP
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
revert changes in ASM
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
use Files.copy in MLet
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
use Files.copy
On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman wrote:
> One or two of the sources changes should probably uses Files.copy, e.g.
> ZipPath, sjavac/CopyFile.java.
Good idea! Replaced in few places. But not in ZipPath: it's actually
implementation of underlying call from Files.copy:
`jdk.nio.zip
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request conta
On Sun, 20 Dec 2020 22:48:24 GMT, Sergey Bylokhov wrote:
>> So these changes are all over the place which means no one person knows how
>> to test all of it.
>> Have you run the sound, swing tests, and the printing tests on unix and
>> windows ?
>> For printing for sure you'll need to do some
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request conta
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
revert changes in Apa
On Mon, 21 Dec 2020 09:40:39 GMT, Сергей Цыпанов
wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>&
getColIdxByName(String name) throws SQLException {
RowSetMD = (RowSetMetaDataImpl)this.getMetaData();
if (RowSetMD != null) {
int cols = RowSetMD.getColumnCount();
for (int i = 1; i <= cols; ++i) {
...
Andrey Turbanov
On Mon, 11 Jan 2021 16:57:00 GMT, Aleksei Efimov wrote:
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.base
>
> Hi @turbanoff,
> This PR is ready for integration - `JDK-8258657` has been resolved.
> You can proceed with issuing `integrate` bot command. Then I
On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov
wrote:
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
This pull request has now been integrated.
Changeset: 022bc9f0
Author:Andrey Turbanov
Committer: Aleksei Efimov
URL:
On Mon, 8 Feb 2021 14:01:34 GMT, Alan Bateman wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>> reve
On Mon, 8 Feb 2021 16:19:17 GMT, Julia Boes wrote:
>> Andrey Turbanov has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR.
>
> src/jav
On Mon, 8 Feb 2021 14:38:52 GMT, Weijun Wang wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>> reve
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
On Fri, 12 Feb 2021 21:03:04 GMT, Andrey Turbanov
wrote:
>> I've updated the issue summary to better reflect the changes, the PR summary
>> should be renamed accordingly.
>> As mentioned earlier, have you run the tests for the affected areas? Here's
>>
On Fri, 12 Feb 2021 21:04:54 GMT, Andrey Turbanov
wrote:
>> I rebased my changes onto master. (commit
>> 837bd8930d0a010110f1318b947c036609d3aa33)
>> and checked tier2 and tier3.
>> What I got:
>>
>> ==
On Mon, 8 Feb 2021 16:39:55 GMT, Julia Boes wrote:
>> The other security-related code changes look good to me.
>
> I've updated the issue summary to better reflect the changes, the PR summary
> should be renamed accordingly.
> As mentioned earlier, have you run the tests for the affected areas?
On Fri, 12 Feb 2021 21:06:24 GMT, Andrey Turbanov
wrote:
>> Then I tried to run tests separately:
>> ## java/io/File/GetXSpace.java
>>
>>
>> make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"
>>
>> STDERR:
>> jav
On Fri, 12 Feb 2021 21:12:14 GMT, Andrey Turbanov
wrote:
>> ## java/net/MulticastSocket/MulticastAddresses.java
>>
>> make test
>> TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"
>>
>> STDOUT:
>> Test:
On Fri, 12 Feb 2021 21:32:04 GMT, Andrey Turbanov
wrote:
>> ## java/net/MulticastSocket/SetLoopbackMode.java
>>
>> make test
>> TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
>>
>>
>> STDOUT:
>>
On Fri, 12 Feb 2021 21:53:13 GMT, Andrey Turbanov
wrote:
>> ## java/nio/file/Files/CopyAndMove.java
>>
>> make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
>>
>> STDOUT:
>> Seed from RandomFactory = 7045320
On Fri, 12 Feb 2021 22:12:29 GMT, Andrey Turbanov
wrote:
>> ## java/security/AccessController/DoPrivAccompliceTest.java
>>
>> make test
>> TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"
>>
>> STDOUT:
>>
On Sat, 13 Feb 2021 10:20:29 GMT, Andrey Turbanov
wrote:
>> ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java
>>
>> make test
>> TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"
>>
>> ST
java.awt.Font.getPSName(Font.java:1416)
I wonder if this unsynchronized access is expected. Looks like it can
break things when accessed from multiple threads simultaneously.
Do I miss something? Is it done this way, because Font objects are
supposed to be accessed from a single thread only?
Andrey Turbanov
On Thu, 11 Feb 2021 16:02:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
On Thu, 11 Feb 2021 16:02:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
On Thu, 11 Feb 2021 16:02:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.tran
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.tran
On Mon, 15 Feb 2021 19:23:16 GMT, Alan Bateman wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>> re
On Mon, 8 Feb 2021 21:18:44 GMT, Philippe Marschall
wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>
On Tue, 9 Feb 2021 11:40:09 GMT, Philippe Marschall
wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.tran
On Tue, 16 Feb 2021 17:20:37 GMT, Julia Boes wrote:
>> 8080272 Refactor I/O stream copying to use
>> InputStream.transferTo/readAllBytes and Files.copy
>
> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall -
> have they been addressed?
> https://github.com/openjdk/jdk/pu
On Thu, 18 Feb 2021 19:21:45 GMT, Sean Mullan wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>
>The last implementation is available in pre-Skara webrev form, as referenced
>in [2]
Hope to see it as a github review soon!
Andrey Turbanov
On Fri, 19 Feb 2021 15:03:11 GMT, Sean Mullan wrote:
>> As I can see only ByteArrayInputStream is actually passed in `InputStream`
>> in current JDK code:
>>
>> PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
>> private static List parsePKCS7(InputStream is)
>> certs = parse
On Wed, 10 Mar 2021 16:40:56 GMT, Claes Redestad wrote:
>> Nice catch!
>>
>> We have a test that is supposed to test this:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java
>> But it is only checking if an NPE is thrown, and not checking for a
>> message, sinc
On Sat, 20 Feb 2021 12:17:32 GMT, Сергей Цыпанов
wrote:
> This is a very simple and trivial improvement about getting rid of pointless
> char wrapping into array
Marked as reviewed by turban...@github.com (no known OpenJDK username).
I think it's worth to cleanup other places with similar cod
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272 Refactor I/O stream copying to use
InputStream.transferTo/readAl
On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov
wrote:
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
This pull request has now been integrated.
Changeset: 68deb24b
Author:Andrey Turbanov
Committer: Julia Boes
URL:
Found by IntelliJ IDEA inspection `Java | Java language level migration aids |
Java 5 | 'StringBuffer' may be 'StringBuilder'`
As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003
I've created separate PR for module `java.base`
Similar cleanup in the past - https://bugs
On Tue, 23 Feb 2021 16:13:21 GMT, liach
wrote:
>This shouldn't be a problem.
What do you mean by "this"? Double racy read?
There are 2 separate reads of fields. First can return non-null value, while
second still can get `null`
> src/java.base/share/classes/java/lang/Runtime.java line 824:
>
Avoid double-read non volatile static field
-
Commit messages:
- [PATCH] Thread-safe initialization of Runtime.version
Changes: https://git.openjdk.java.net/jdk/pull/2691/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2691&range=00
Issue: https://bugs.openjdk.java.ne
On Tue, 23 Feb 2021 16:59:45 GMT, liach
wrote:
>>>This shouldn't be a problem.
>>
>> What do you mean by "this"? Double racy read?
>> There are 2 separate reads of fields. First can return non-null value, while
>> second still can get `null`
>
>> There are 2 separate reads of fields. First can
On Tue, 23 Feb 2021 13:23:44 GMT, Andrey Turbanov
wrote:
> Avoid double-read non volatile static field
This pull request has now been integrated.
Changeset: 23353626
Author: Andrey Turbanov
Committer: Aleksey Shipilev
URL: https://git.openjdk.java.net/jdk/commit/23353626
St
On Tue, 23 Mar 2021 12:38:06 GMT, Pavel Rappo wrote:
>> Found by IntelliJ IDEA inspection `Java | Java language level migration aids
>> | Java 5 | 'StringBuffer' may be 'StringBuilder'`
>> As suggested in
>> https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created
>> separa
On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov
wrote:
> Found by IntelliJ IDEA inspection `Java | Java language level migration aids
> | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in
> https://github.com/openjdk/jdk/pull/1507#iss
On Fri, 16 Apr 2021 11:30:32 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 Wed, 21 Apr 2021 11:06:16 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.time`
>> package to make use of the `instanceof` pattern variable?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request w
I propose to remove 'null' assignment of field CompactByteArray.values in
`expand` method. In the next statement this field is overridden with another
value - `tempArray`.
This code was there from initial load of OpenJDK sources. I believe it was just
leftovers from development phase of this cla
On Wed, 23 Dec 2020 16:06:30 GMT, Andrey Turbanov
wrote:
> I propose to remove 'null' assignment of field CompactByteArray.values in
> `expand` method. In the next statement this field is overridden with another
> value - `tempArray`.
> This code was there from initial l
On Tue, 15 Jun 2021 16:05:06 GMT, Michael Bien
wrote:
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
>> use `ArrayList` if a thread-safe implementation is not needed.
>> I checked only places where `Vector` was used as local variable.
>
> src/java.base/share/cla
Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
use `ArrayList` if a thread-safe implementation is not needed.
I checked only places where `Vector` was used as local variable.
-
Commit messages:
- [PATCH] Unnecessary Vector usage in java.base
- [PATCH]
On Wed, 16 Jun 2021 09:01:30 GMT, Сергей Цыпанов
wrote:
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
>> use `ArrayList` if a thread-safe implementation is not needed.
>> I checked only places where `Vector` was used as local variable.
>
> src/java.base/share/c
I found few places, where code initially perform `Object[]
Colleciton.toArray()` call and then manually copy array into another array with
required type.
This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.
-
Commit messages:
- Replace usages of Collecti
On Tue, 15 Jun 2021 12:06:43 GMT, Michael Bien
wrote:
>> I found few places, where code initially perform `Object[]
>> Colleciton.toArray()` call and then manually copy array into another array
>> with required type.
>> This PR cleanups such places to more shorter call `T[]
>> Collection.toAr
On Wed, 23 Dec 2020 16:06:30 GMT, Andrey Turbanov
wrote:
> I propose to remove 'null' assignment of field CompactByteArray.values in
> `expand` method. In the next statement this field is overridden with another
> value - `tempArray`.
> This code was there from initial l
On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov
wrote:
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
> use `ArrayList` if a thread-safe implementation is not needed. In
> post-BiasedLocking times, this is gets worse, as every access is syn
On Mon, 26 Jul 2021 19:55:09 GMT, Brett Okken
wrote:
>> I found few places, where code initially perform `Object[]
>> Colleciton.toArray()` call and then manually copy array into another array
>> with required type.
>> This PR cleanups such places to more shorter call `T[]
>> Collection.toArr
On Mon, 26 Jul 2021 19:15:55 GMT, Brett Okken
wrote:
>> I found few places, where code initially perform `Object[]
>> Colleciton.toArray()` call and then manually copy array into another array
>> with required type.
>> This PR cleanups such places to more shorter call `T[]
>> Collection.toArr
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more sho
s this condition is always false.
Reproducer:
BigInteger a = new BigInteger(1073742825, ThreadLocalRandom.current());
BigInteger b = new BigInteger(1073742825, ThreadLocalRandom.current());
BigInteger c = a.multiply(b);
Andrey Turbanov
remove redundant if
-
Commit messages:
- 8272616: Strange code in java.text.DecimalFormat#applyPattern
Changes: https://git.openjdk.java.net/jdk/pull/5171/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5171&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-827
On Wed, 18 Aug 2021 20:59:20 GMT, Andrey Turbanov
wrote:
> remove redundant if
This pull request has now been integrated.
Changeset: 51c1b9a6
Author: Andrey Turbanov
Committer: Brian Burkhalter
URL:
https://git.openjdk.java.net/jdk/commit/51c1b9a6870bd9644e92227e47082a53e2d1c
Collections.sort is just a wrapper, so it is better to use an instance method
directly.
-
Commit messages:
- [PATCH] Replace usages of Collections.sort with List.sort call in public
java modules
Changes: https://git.openjdk.java.net/jdk/pull/5229/files
Webrev: https://webrevs.ope
dGenerator
sun.security.util.ByteArrayTagOrder
sun.security.util.IOUtils
Andrey Turbanov
On Tue, 24 Aug 2021 11:48:46 GMT, Alexander Zvegintsev
wrote:
> Is there any reason to not touch them along with this fix?
Update them too.
-
PR: https://git.openjdk.java.net/jdk/pull/5229
> Collections.sort is just a wrapper, so it is better to use an instance method
> directly.
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8272863: Replace usages of Collections.sort with List.sort call in public
java m
On Wed, 25 Aug 2021 08:29:57 GMT, Daniel Fuchs wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8272863: Replace usages of Collections.sort with List.sort call in public
>
> Collections.sort is just a wrapper, so it is better to use an instance method
> directly.
Andrey Turbanov has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of
On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov
wrote:
> Collections.sort is just a wrapper, so it is better to use an instance method
> directly.
This pull request has now been integrated.
Changeset: d732c309
Author:Andrey Turbanov
Committer: Sergey Bylokhov
URL:
Predicate.union(RegexpBug.java:20)
at org.RegexpBug.main(RegexpBug.java:5)
As I can see this method is never used. Perhaps it should be removed?
Andrey Turbanov
Usage of thread-safe collection Vector is unnecessary. It's recommended to use
ArrayList/array if a thread-safe implementation is not needed. In
post-BiasedLocking times, this is gets worse, as every access is synchronized.
I checked only places where Vector was used as local variable.
-
On Thu, 26 Aug 2021 07:04:45 GMT, Andrey Turbanov
wrote:
> Usage of thread-safe collection Vector is unnecessary. It's recommended to
> use ArrayList/array if a thread-safe implementation is not needed. In
> post-BiasedLocking times, this is gets worse, as every access is syn
1 - 100 of 352 matches
Mail list logo
