As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason
to explicitly instantiate any instance of `Atomic*` class with its default
value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()`
which is faster:
@State(Scope.Thread)
@OutputTimeUnit(TimeUni
On Fri, 23 Oct 2020 09:12:15 GMT, Daniel Fuchs wrote:
>> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
>> reason to explicitly instantiate any instance of `Atomic*` class with its
>> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
>> AtomicInte
Hello, while working with `java.net.URL` I've found unused package-private
method `URL.set(String protocol, String host, int port, String file, String
ref)` which can be safely removed from JDK. Testing: tier1, tier2
Could someone crate an issue for tracking of this simple change?
-
On Tue, 27 Oct 2020 19:26:04 GMT, Aleksey Shipilev wrote:
>> Hello, while working with `java.net.URL` I've found unused package-private
>> method `URL.set(String protocol, String host, int port, String file, String
>> ref)` which can be safely removed from JDK. Testing: tier1, tier2
>>
>> Coul
On Sat, 24 Oct 2020 23:12:09 GMT, Phil Race wrote:
>> Сергей Цыпанов 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 contains one add
citValue avgt 30 11.846 ± 0.273 ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in
> progress we could trivially replace explicit zeroing with default
> constructors gaining some performance benefit with no risk.
>
> I've tested the changes locally, both tier1 an
On Wed, 28 Oct 2020 08:49:38 GMT, Sergey Bylokhov wrote:
>> Rebased onto master to have the fix introduced in
>> https://github.com/openjdk/jdk/pull/778
>
> FYI it is better to use merge, instead of rebase+force push. Rebase breaks
> history and all existed code comments.
@mrserb thanks for po
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced
On Wed, 25 Nov 2020 08:02:07 GMT, Aleksey Shipilev wrote:
>> @shipilev thanks for filing the issue! Done.
>
> Please merge from master to get a fresh round of testing. @AlanBateman might
> want to look at it.
Done!
-
PR: https://git.openjdk.java.net/jdk/pull/779
f this simple change?
Сергей Цыпанов 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 contains two additional
commits since the last revision:
- Merge bran
On Wed, 25 Nov 2020 13:31:06 GMT, Daniel Fuchs wrote:
>> Done!
>
> I'll have a look at this when I can spare some cycles. @stsypanov did you run
> tier2 tests?
@dfuch
Recent run has some errors:
java/net/MulticastSocket/SetOutgoingIf.java: Re-test IPv6 (and specifically
MulticastSocket) with
On Wed, 21 Oct 2020 06:52:42 GMT, Сергей Цыпанов
wrote:
> Hello, while working with `java.net.URL` I've found unused package-private
> method `URL.set(String protocol, String host, int port, String file, String
> ref)` which can be safely removed from JDK. Testing: tier1, ti
On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov
wrote:
>> 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
On Mon, 21 Dec 2020 09:51:25 GMT, Andrey Turbanov
wrote:
>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
>>
>>> 2457: byte[] bytes = in.readAllBytes();
>>> 2458: return
>>> CertificateFactory.getInstance("X509").generateCRLs(
>>> 2
Instead of allocating a copy of underlying array via
`CharArrayWriter.toCharArray()` and passing it to constructor of String
String str = new String(charArrayWriter.toCharArray());
we could call `toString()` method
String str = charArrayWriter.toString();
decoding existing char[] without making a
On Sun, 10 Jan 2021 20:13:51 GMT, Attila Szegedi wrote:
>> Instead of allocating a copy of underlying array via
>> `CharArrayWriter.toCharArray()` and passing it to constructor of String
>> String str = new String(charArrayWriter.toCharArray());
>> we could call `toString()` method
>> String str
On Wed, 13 Jan 2021 13:48:40 GMT, Claes Redestad wrote:
>> Instead of allocating a copy of underlying array via
>> `CharArrayWriter.toCharArray()` and passing it to constructor of String
>> String str = new String(charArrayWriter.toCharArray());
>> we could call `toString()` method
>> String str
On Wed, 13 Jan 2021 13:48:40 GMT, Claes Redestad wrote:
>> Instead of allocating a copy of underlying array via
>> `CharArrayWriter.toCharArray()` and passing it to constructor of String
>> String str = new String(charArrayWriter.toCharArray());
>> we could call `toString()` method
>> String str
> 0.006 ± 0.001 MB/sec
> UrlEncoderBenchmark.encodeUtf8:·gc.churn.G1_Survivor_Space.norm avgt 100
> 0.010 ± 0.002B/op
> UrlEncoderBenchmark.encodeUtf8:·gc.count avgt 100
> 655.000 counts
> UrlEncoderBenchmark.encodeUtf8:·gc.time
> 0.006 ± 0.001 MB/sec
> UrlEncoderBenchmark.encodeUtf8:·gc.churn.G1_Survivor_Space.norm avgt 100
> 0.010 ± 0.002B/op
> UrlEncoderBenchmark.encodeUtf8:·gc.count avgt 100
> 655.000 counts
> UrlEncoderBenchmark.encodeUtf8:·gc.time
On Wed, 13 Jan 2021 13:48:40 GMT, Claes Redestad wrote:
>> Сергей Цыпанов 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 contai
On Thu, 3 Dec 2020 14:29:58 GMT, Сергей Цыпанов
wrote:
> Instead of allocating a copy of underlying array via
> `CharArrayWriter.toCharArray()` and passing it to constructor of String
> String str = new String(charArrayWriter.toCharArray());
> we could call `toString()` method
Non-static classes hold a link to their parent classes, which in many cases can
be avoided.
-
Commit messages:
- 8261880: Change nested classes in java.base to static nested classes where
possible
Changes: https://git.openjdk.java.net/jdk/pull/2589/files
Webrev: https://webrevs.o
On Wed, 17 Feb 2021 16:24:46 GMT, Claes Redestad wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8261880: Remove static from declarations of Holder nested classes
>
> src/java.base/
> Non-static classes hold a link to their parent classes, which in many cases
> can be avoided.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8261880: Remove static from declarations of Holder nested c
On Wed, 24 Feb 2021 08:50:36 GMT, Alan Bateman wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8261880: Remove static from declarations of Holder nested classes
>
> src/java.b
On Sun, 14 Mar 2021 07:51:24 GMT, Alan Bateman wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to reading
In some cases wrapping of `InputStream` with `BufferedInputStream` is
redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does
not require any buffer having one within.
Other cases are related to reading either a byte or short `byte[]`: in both
cases `BufferedInputStream.fi
On Fri, 26 Feb 2021 15:32:57 GMT, liach
wrote:
> Are linked lists worse for addition even in cases where addition to array
> list or deque requires resize and copying? i thought that's the advantage of
> linked list.
As far as I know `LinkedList` is always worse than `ArrayList` and discourag
The usage of `LinkedList` is senseless and can be replaced with either
`ArrayList` or `ArrayDeque` which are both more compact and effective.
jdk:tier1 and jdk:tier2 are both ok
-
Commit messages:
- Remove remaining usages of LinkedList in java.base
Changes: https://git.openjdk.ja
On Sun, 14 Mar 2021 15:02:03 GMT, liach
wrote:
>> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220:
>>
>>> 218: return Collections.emptyList();
>>> 219: }
>>> 220: List result = new ArrayList<>();
>>
>> We'd better be cautious about this re
n both
> cases `BufferedInputStream.fill()` will be called resulting in load of much
> bigger amount of data (8192 by default) than required.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
Revert usage of InputStream.readNBytes()
-
On Sun, 14 Mar 2021 11:16:13 GMT, Alan Bateman wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert usage of InputStream.readNBytes()
>
> src/java.base/share/classes/jdk/inter
On Sun, 14 Mar 2021 17:26:07 GMT, Alan Bateman wrote:
>> Looks like it's never specified in JavaDoc which particular implementation
>> of List is used in fields of affected classes, so it's quite odd to me that
>> someone would rely on that when using reflection. But your point about
>> backwa
On Sun, 14 Mar 2021 17:40:27 GMT, Alan Bateman wrote:
>> It turned out, that with this latest update some of tier2_tools tests are
>> failing, e.g. `JLinkNegativeTest`:
>> test JLinkNegativeTest.testMalformedJmod(): failure
>> java.lang.AssertionError: Output does not fit regexp: Error:
>> java
n both
> cases `BufferedInputStream.fill()` will be called resulting in load of much
> bigger amount of data (8192 by default) than required.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
Use InputStream.readNBytes() and
On Sun, 14 Mar 2021 22:48:18 GMT, Sergey Bylokhov wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use InputStream.readNBytes() and fix JLinkNegativeTest
>
> src/java.deskt
n both
> cases `BufferedInputStream.fill()` will be called resulting in load of much
> bigger amount of data (8192 by default) than required.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
Fix formatting
-
Ch
n both
> cases `BufferedInputStream.fill()` will be called resulting in load of much
> bigger amount of data (8192 by default) than required.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
Fix error message
-
Ch
On Mon, 15 Mar 2021 11:41:07 GMT, Alan Bateman wrote:
>> Done
>
>> Done
>
> I think I'd prefer if the exception message would say that the JMOD is
> invalid or that the JMOD file is truncated (because I don't think anyone
> seeing this exception will know anything about the header).
Fixed
--
On Mon, 15 Mar 2021 15:04:49 GMT, Daniel Fuchs wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix error message
>
> src/java.base/share/classes/sun/net/www/http/HttpC
n both
> cases `BufferedInputStream.fill()` will be called resulting in load of much
> bigger amount of data (8192 by default) than required.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
Revert HttpClient
-
Ch
On Sat, 13 Mar 2021 22:29:23 GMT, Сергей Цыпанов
wrote:
> In some cases wrapping of `InputStream` with `BufferedInputStream` is
> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does
> not require any buffer having one within.
>
> Other cases are rel
When we do
byte b1 = (byte) (value & 0xFF);
we keep from int only 1 lower byte and exactly the same can be achieved with
plain cast. See the test below:
public class Main {
public static void main(String[] args) throws Exception {
IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach
On Mon, 15 Mar 2021 06:56:00 GMT, Alan Bateman wrote:
>> Nothing outside of the JDK should be hacking into this private field of a
>> non-exposed class, this should not be a concern here.
>
>> @AlanBateman so is it ok to keep `ArrayLists`?
>
> One thing to look out for is usages of 2-arg add me
On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов
wrote:
>> Non-static classes hold a link to their parent classes, which in many cases
>> can be avoided.
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
&
On Thu, 20 May 2021 10:42:49 GMT, Claes Redestad wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8261880: Remove static from declarations of Holder nested classes
>
> Marked as
On Tue, 16 Feb 2021 14:30:58 GMT, Сергей Цыпанов
wrote:
> Non-static classes hold a link to their parent classes, which in many cases
> can be avoided.
This pull request has now been integrated.
Changeset: 9425d3de
Author:Sergey Tsypanov
Committer: Claes Redestad
URL:
On Fri, 26 Feb 2021 10:48:33 GMT, Сергей Цыпанов
wrote:
> The usage of `LinkedList` is senseless and can be replaced with either
> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>
> jdk:tier1 and jdk:tier2 are both ok
Hi guys, any more comments here? Pleas
On Fri, 21 May 2021 14:15:53 GMT, Daniel Fuchs wrote:
>> The usage of `LinkedList` is senseless and can be replaced with either
>> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>>
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/j
On Fri, 21 May 2021 14:18:16 GMT, Daniel Fuchs wrote:
>> The usage of `LinkedList` is senseless and can be replaced with either
>> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>>
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/j
On Fri, 21 May 2021 15:12:20 GMT, Thiago Henrique Hüpner
wrote:
>>> IcedTea-Web seems to be using this method reflectively:
>>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
>>
>> I assume this doesn'
On Mon, 24 May 2021 09:25:08 GMT, liach
wrote:
>> Should we then revert the changes to `JarIndex`?
>
> But don't people access these internal code at their own risk, as jdk may
> change these code at any time without notice?
True, I just wonder whether it's OK to change internals when we know
> The usage of `LinkedList` is senseless and can be replaced with either
> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>
> jdk:tier1 and jdk:tier2 are both ok
Сергей Цыпанов has refreshed the contents of this pull request, and previous
commits have been
> The usage of `LinkedList` is senseless and can be replaced with either
> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>
> jdk:tier1 and jdk:tier2 are both ok
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the l
> The usage of `LinkedList` is senseless and can be replaced with either
> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>
> jdk:tier1 and jdk:tier2 are both ok
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a
On Fri, 26 Feb 2021 10:48:33 GMT, Сергей Цыпанов
wrote:
> The usage of `LinkedList` is senseless and can be replaced with either
> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>
> jdk:tier1 and jdk:tier2 are both ok
This pull request has been closed w
After I've renamed remove branch GitHub for some reason has closed original
https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
-
Commit messages:
- Merge branch 'master' into 8263561
- Merge branch 'master' into purge-linked-list
- 8263561: Use sized constru
> After I've renamed remove branch GitHub for some reason has closed original
> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contai
There is an optimization opportunity for the widespread use-case when a
resource is read from classpath using
`getClass().getClassLoader().getResource()` or
`getClass().getClassLoader().getResourceAsStream()`.
Pay attention to lines starting from 261. In case I run something like
var props = g
On Fri, 18 Jun 2021 07:31:14 GMT, Сергей Цыпанов
wrote:
> There is an optimization opportunity for the widespread use-case when a
> resource is read from classpath using
> `getClass().getClassLoader().getResource()` or
> `getClass().getClassLoader().getResourceAsStream()`.
>
On Tue, 22 Jun 2021 11:59:11 GMT, Daniel Fuchs wrote:
>> There is an optimization opportunity for the widespread use-case when a
>> resource is read from classpath using
>> `getClass().getClassLoader().getResource()` or
>> `getClass().getClassLoader().getResourceAsStream()`.
>>
>> Pay attenti
ourceBenchmark.getResource:·gc.churn.G1_Survivor_Space avgt
> 100 0,008 ± 0,005 MB/sec
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Survivor_Space.norm avgt
> 100 0,017 ± 0,010B/op
> ClassGetResourceBenchmark.getResource:·gc.count avgt
> 10070,
> After I've renamed remove branch GitHub for some reason has closed original
> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contai
On Fri, 2 Jul 2021 13:57:47 GMT, Daniel Fuchs wrote:
>> Сергей Цыпанов 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 contain
ourceBenchmark.getResource:·gc.churn.G1_Survivor_Space avgt
> 100 0,008 ± 0,005 MB/sec
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Survivor_Space.norm avgt
> 100 0,017 ± 0,010B/op
> ClassGetResourceBenchmark.getResource:·gc.count avgt
> 100
> After I've renamed remove branch GitHub for some reason has closed original
> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The pull request now cont
> After I've renamed remove branch GitHub for some reason has closed original
> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The pull request now con
> After I've renamed remove branch GitHub for some reason has closed original
> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The pull request now con
On Wed, 2 Jun 2021 12:10:46 GMT, Сергей Цыпанов
wrote:
> After I've renamed remove branch GitHub for some reason has closed original
> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
This pull request has now been integrated.
Changeset: 249d6418
A
On Wed, 23 Jun 2021 10:03:48 GMT, Сергей Цыпанов
wrote:
>> Hi Sergey,
>>
>> That exception means you're using an obsolete version of jtreg: you need
>> jtreg-6+1 now.
>>
>> best regards,
>> -- daniel
>
> @dfuch I've fixed the issue an
On Fri, 18 Jun 2021 07:31:14 GMT, Сергей Цыпанов
wrote:
> There is an optimization opportunity for the widespread use-case when a
> resource is read from classpath using
> `getClass().getClassLoader().getResource()` or
> `getClass().getClassLoader().getResourceAsStream()`.
>
There are unused methods/constructors in mentioned classes that can be safely
removed.
-
Commit messages:
- 8276166: Remove dead code from MimeTable and MimeEntry
Changes: https://git.openjdk.java.net/jdk/pull/6169/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6169&r
On Fri, 29 Oct 2021 11:20:57 GMT, Сергей Цыпанов wrote:
> There are unused methods/constructors in mentioned classes that can be safely
> removed.
Let's wait a bit
-
PR: https://git.openjdk.java.net/jdk/pull/6169
Instead of something like
long x;
long y;
return (x < y) ? -1 : ((x == y) ? 0 : 1);
we can use `return Long.compare(x, y);`
All replacements are done with IDE.
-
Commit messages:
- 8277868: Use Comparable.compare() instead of surrogate code
Changes: https://git.openjdk.java.net/j
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
Сергей Цыпанов has updated the pull request incrementally with one additional
On Sat, 27 Nov 2021 22:50:55 GMT, Michael Bien wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/
On Mon, 6 Dec 2021 17:46:22 GMT, Phil Race wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/java
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
Сергей Цыпанов has updated the pull request incrementally with one additional
On Mon, 6 Dec 2021 17:48:37 GMT, Phil Race wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
Сергей Цыпанов has updated the pull request incrementally with two additional
c
On Tue, 7 Dec 2021 12:01:27 GMT, Alexey Ivanov wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277868: Inline local var
>
> src/java.base/share/classes/java/util/Calendar.java line
On Fri, 26 Nov 2021 12:46:59 GMT, Сергей Цыпанов wrote:
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
This pull request has n
On Fri, 29 Oct 2021 11:20:57 GMT, Сергей Цыпанов wrote:
> There are unused methods/constructors in mentioned classes that can be safely
> removed.
Not now
-
PR: https://git.openjdk.java.net/jdk/pull/6169
On Wed, 19 Jan 2022 16:55:44 GMT, Julia Boes wrote:
>> Not now
>
> Happy to /sponsor once you /integrate, @stsypanov.
@FrauBoes thanks!
-
PR: https://git.openjdk.java.net/jdk/pull/6169
On Fri, 29 Oct 2021 11:20:57 GMT, Сергей Цыпанов wrote:
> There are unused methods/constructors in mentioned classes that can be safely
> removed.
This pull request has now been integrated.
Changeset: cf977e88
Author:Sergey Tsypanov
Committer: Julia Boes
URL:
- use `String.equalsIgnoreCase()` instead of hand-written code relying on
`String.charAt()`
- use `String.compareToIgnoreCase()` instead of hand-written code relying on
`String.charAt()`
- drop branches that are never executed
- drop unused argument from `URI.resolvePath()`
- simplify String-rela
On Tue, 26 Apr 2022 11:35:10 GMT, Daniel Fuchs wrote:
>> - use `String.equalsIgnoreCase()` instead of hand-written code relying on
>> `String.charAt()`
>> - use `String.compareToIgnoreCase()` instead of hand-written code relying on
>> `String.charAt()`
>> - drop branches that are never executed
On Tue, 26 Apr 2022 07:02:55 GMT, Сергей Цыпанов wrote:
> - use `String.equalsIgnoreCase()` instead of hand-written code relying on
> `String.charAt()`
> - use `String.compareToIgnoreCase()` instead of hand-written code relying on
> `String.charAt()`
> - drop branches that are
On Thu, 19 May 2022 12:19:25 GMT, ExE Boss wrote:
>> - use `String.equalsIgnoreCase()` instead of hand-written code relying on
>> `String.charAt()`
>> - use `String.compareToIgnoreCase()` instead of hand-written code relying on
>> `String.charAt()`
>> - drop branches that are never executed
>>
On Tue, 26 Apr 2022 07:02:55 GMT, Сергей Цыпанов wrote:
> - use `String.equalsIgnoreCase()` instead of hand-written code relying on
> `String.charAt()`
> - use `String.compareToIgnoreCase()` instead of hand-written code relying on
> `String.charAt()`
> - drop branches that are
m `URI.resolvePath()`
> - simplify String-related operations
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8285521: Revert wrong changes
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8397/files
- new: https://git
92 matches
Mail list logo
