Result of string concatenation is a newly created `String` object. There is no
need it wrap it in another `new String` call.
Such calls are confusing and produce warnings in IDE. Without them code is
easier to read.
-
Commit messages:
- [PATCH] Remove redundant 'new String' calls a
as local variable.
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8271603: Unnecessary Vector usage in java.desktop
one more place to call toArray with zero-sized array
-
Changes:
- all: https://git.openjdk.java.
On Fri, 3 Sep 2021 03:17:02 GMT, Sergey Bylokhov wrote:
>> Andrey Turbanov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains eight commits:
>>
>> - Merge remote-tracking branch 'origin/master'
as local variable.
Andrey Turbanov has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains eight commits:
- Merge remote-tracking branch 'origin/master' into
avoid-unnecessary-vector-usage-in-java.desktop
# Conflicts:
as local variable.
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8271603: Unnecessary Vector usage in java.desktop
use toArray with zero sized array in places where Vector.copyInto was used
-
Change
On Fri, 27 Aug 2021 18:28:58 GMT, Sergey Bylokhov wrote:
>> Can you please elaborate?
>> As I can see if size of array is exactly the same as size of
>> vector/arraylist, implementations are similar - they just call
>> System.arraycopy
>> ` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more sho
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, 5 Jul 2021 14:03:18 GMT, Сергей Цыпанов
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
>> synchronized.
>> I
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 synchronized.
I checked only places where `Vector` was used as local variable.
-
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 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
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 Mon, 29 Mar 2021 20:50:14 GMT, Andrey Turbanov
wrote:
> There are few possible cleanups in java.desktop related to legacy
> StringBuffer usages:
> 1. In few places StringBuffer can be replaced with plain String concatenation.
> 2. StringBuffer can be replaced with S
h specialized methods (like
> `.append(int)` calls.
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
place each 'append' call on its own line
On Wed, 7 Apr 2021 15:21:40 GMT, Alexey Ivanov wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
>>
&
On Tue, 30 Mar 2021 15:46:56 GMT, Alexander Zvegintsev
wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
>&
h specialized methods (like
> `.append(int)` calls.
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
[PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
fix copyright year
-
Changes:
- all: https:/
On Wed, 31 Mar 2021 21:12:37 GMT, Sergey Bylokhov wrote:
>> Submitted: https://bugs.openjdk.java.net/browse/JDK-8264428, please rename
>> PR to "8264428: Replace uses of StringBuffer with StringBuilder in
>> java.desktop".
>
> Looks like this change goes beyond of simple replacement of StringB
On Tue, 30 Mar 2021 18:31:34 GMT, Andrey Turbanov
wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
>
> src/
`java.desktop`
> Similar cleanups in the past:
> https://bugs.openjdk.java.net/browse/JDK-8041679
> https://bugs.openjdk.java.net/browse/JDK-8264029
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
[PATCH] Replace uses o
On Mon, 29 Mar 2021 20:50:14 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
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.desktop`
Similar cleanups in the past: https://b
On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov
wrote:
> Cleanup code to use new handy methods in
> `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
> 1. java.io.InputStream#readAllBytes
> 2. java.io.InputStream#transferTo
> 3. java.nio.file.Files#
On Tue, 23 Feb 2021 15:47:20 GMT, Prasanta Sadhukhan
wrote:
>> Cleanup code to use new handy methods in
>> `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
>> 1. java.io.InputStream#readAllBytes
>> 2. java.io.InputStream#transferTo
>> 3. java.nio.file.Files#copy
>>
>>
On Sun, 3 Jan 2021 03:08:31 GMT, Sergey Bylokhov wrote:
>> Cleanup code to use new handy methods in
>> `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
>> 1. java.io.InputStream#readAllBytes
>> 2. java.io.InputStream#transferTo
>> 3. java.nio.file.Files#copy
>>
>> Simi
Cleanup code to use new handy methods in
`java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
1. java.io.InputStream#readAllBytes
2. java.io.InputStream#transferTo
3. java.nio.file.Files#copy
Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272
-
Co
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 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
> 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
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
revert changes in JrtP
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.
On Wed, 2 Dec 2020 19:23:28 GMT, Andrey Turbanov
wrote:
> There are few places in code where manual `while` loop is used with
> `Iterator` to iterate over `Collection`.
> Instead of manual `while` cycles it's preferred to use _enhanced-for_ cycle
> instead: it's le
On Wed, 16 Dec 2020 14:59:45 GMT, Andrey Turbanov
wrote:
>> These tests more or less *never* fail so how are you sure it is not your
>> changes ?
>> And 8 beans tests failed and you made 3 changes in beans code so I'd like to
>> see some evidence
>> to show
On Tue, 15 Dec 2020 21:14:08 GMT, Phil Race wrote:
>> I've run `test-tier3`. 15 tests failed. Looks like they are not related to
>> my changes:
>>
>> JT Harness : Tests that failed
>> Tests are grouped by their final status message.
>> Execution failed: `main' threw exception: TestF
On Mon, 14 Dec 2020 20:04:05 GMT, Phil Race wrote:
>> I've added few words in description.
>>
>> About testing: as I can see testing is done via Github Actions. tier1 builds
>> are ok.
>
>> I've added few words in description.
>>
>> About testing: as I can see testing is done via Github Action
error-prone.
> It doesn't have any performance impact: java compiler generates similar code
> when compiling _enhanced-for_ cycle.
>
> See similar cleanup in C++ code - #1707
Andrey Turbanov has updated the pull request with a new target base due to a
merge or a rebase. The p
On Sat, 12 Dec 2020 23:05:35 GMT, Phil Race wrote:
>> The bug is filed:
>> https://bugs.openjdk.java.net/browse/JDK-8258006
>
> Whilst this looks "reasonable" I am not impressed by the complete lack of
> description of
> 1) why this is being proposed
> 2) what are the benefits
> 3) what testing
8258006: Replaces while cycles with iterator with enhanced for in java.desktop
-
Commit messages:
- [PATCH] Replaces while cycles with iterator with enhanced for in java.desktop
Changes: https://git.openjdk.java.net/jdk/pull/1574/files
Webrev: https://webrevs.openjdk.java.net/?repo
On Sat, 28 Nov 2020 20:12:57 GMT, Andrey Turbanov
wrote:
> Looks like extended key codes set was filled with _synonyms_
> https://wiki.linuxquestions.org/wiki/List_of_Keysyms_Recognised_by_Xmodmap
> `0x10006cc` is a _Farsi_yeh_ and also deprecated synonym _Arabic_farsi_yeh_
> `0x10
Hello.
I would like to contribute small patch to fix repeated words typos.
Andrey Turbanov
diff --git
a/src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameManager.java
b/src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameManager.java
index c2ce10b0e4a..ccd65105699
58 matches
Mail list logo
