JarAccess() {
if (javaUtilJarAccess == null) {
-// Ensure JarFile is initialized; we know that that class
+// Ensure JarFile is initialized; we know that this class
// provides the shared secret
unsafe.ensureClassInitialized(JarFile.class);
}
Andrey Turbanov.
ttempt to
+ * is registered via a call to
RMISocketFactory.setFailureHandler.
+ * If no failure handler is installed, the default behavior is to
attempt to
* re-create the ServerSocket.
*
* @param ex the exception that occurred during ServerSocket
Andrey Turbanov
>+ * {@code RMISocketFactory.setFailureHandler}. If no failure
One redundant space before "If"
Andrey Turbanov
> On 28/01/2019 17:04, Lance Andersen wrote:
> > The updates look fine
> >> - * This includes the case where a module reads another another with
> >> the
> >> + * This includes the case where a module reads another with the
> >>
> This one is typo, it should say "another module".
>
>
>Could you please re-generate your patch? The reason I'm asking is that the
>current patch contains extra line breaks.
Hm. There wasn't any extra line breaks in sent email. Regenerated
patch attached.
Andre Turbanov
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
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:
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=1677=00
Issue:
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
> 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
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
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
SQLException {
RowSetMD = (RowSetMetaDataImpl)this.getMetaData();
if (RowSetMD != null) {
int cols = RowSetMD.getColumnCount();
for (int i = 1; i <= cols; ++i) {
...
Andrey Turbanov
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 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 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
>&
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/Socket.java:if (bindpoint != null &&
> 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
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:
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
> 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
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:
> 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
use Files.copy in MLet
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:
> 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.c
> 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, 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 load of Ope
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.
>
>
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.
>
>
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
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
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
> 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
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=2691=00
Issue:
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
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:
>
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 -
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 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#issuecomment-757369003
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
>>
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
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:
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,
> 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 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 =
>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, 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
> 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
> 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?
>
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: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
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
>> some
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 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:
)
at 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 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
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 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
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
>>
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
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
sun.security.util.ByteArrayTagOrder
sun.security.util.IOUtils
Andrey Turbanov
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:
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:
te.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
> 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 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
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 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 synchron
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=5171=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8272616
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
w BigInteger(1073742825, ThreadLocalRandom.current());
BigInteger b = new BigInteger(1073742825, ThreadLocalRandom.current());
BigInteger c = a.multiply(b);
Andrey Turbanov
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 less verbose, makes code easier to read and it's less error-prone.
It doesn't have any performance impact:
On Wed, 1 Sep 2021 07:37:53 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 less verbose, makes code ea
After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510)
(eed3a536c0) this condition is always `false`. Empty package name is handled
separately.
Found by IntelliJ inspection.
-
Commit messages:
- [PATCH] Remove redundant zero-length check in ClassDesc.of
Changes:
On Sun, 5 Sep 2021 12:38:20 GMT, Jaikiran Pai wrote:
> Do you mean that converting the keySet() of an
>existing Map into an array and then sorting that array and then using
>that sorted array to iterate and using these keys to do an additional
>lookup for value against the original Map would be
Hello.
I found a confusing javadoc of the method java.lang.StringBuilder#readObject:
"readObject is called to restore the state of the StringBuffer from a stream."
I believe there should be "StringBuilder" instead of "StringBuffer".
Andrey Turbanov
&& cp <= 0x1064 ||
cp >= 0x1062 && cp <= 0x106D ||
The second condition is _wider_ than the first one.
I believe it's a bug. The second condition (according to
https://www.compart.com/en/unicode/category/Mc) should look like this:
cp >= 0x1067 && cp <= 0x106D ||
0x1065, 0x1066 are not from the Spacing_Mark category.
Andrey Turbanov
On Mon, 6 Sep 2021 08:08:33 GMT, Andrey Turbanov
wrote:
> Update code checks both non-null and instance of a class in java.naming
> module classes.
> The checks and explicit casts could also be replaced with pattern matching
> for the instanceof operator.
> For example:
>
mpl.equals(other.impl);
>
>
> See similar cleanup in java.base -
> https://bugs.openjdk.java.net/browse/JDK-8258422
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8273484: Cleanup unnecessary null comparison before instanceof check in
j
On Mon, 6 Sep 2021 08:08:33 GMT, Andrey Turbanov
wrote:
> Update code checks both non-null and instance of a class in java.naming
> module classes.
> The checks and explicit casts could also be replaced with pattern matching
> for the instanceof operator.
> For example:
>
8273710: Remove redundant stream() call before forEach in jdk.jdeps
-
Commit messages:
- [PATCH] Remove redundant stream() call before forEach in jdk.jdeps
Changes: https://git.openjdk.java.net/jdk/pull/5498/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5498=00
Issue:
1 - 100 of 278 matches
Mail list logo
