Re: RFR: 8286849: Use @Stable for generic repositories

2022-05-23 Thread Sergey Bylokhov
On Tue, 17 May 2022 04:40:50 GMT, liach wrote: > Generic repositories, the implementation detail for generic information in > core reflection, can be updated to use the `@Stable` annotation to replace > their `volatile` access. Their existing accessor code is already safe, > reading the cache

Integrated: 8285523: Improve test java/io/FileOutputStream/OpenNUL.java

2022-04-29 Thread Sergey Bylokhov
On Mon, 25 Apr 2022 04:35:13 GMT, Sergey Bylokhov wrote: > The new test added as part of the > [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot > trigger that bug and pass w/ and w/o fix. > > An updated test validates the "default" case when t

Re: RFR: 8285523: Improve test java/io/FileOutputStream/OpenNUL.java

2022-04-28 Thread Sergey Bylokhov
On Thu, 28 Apr 2022 15:43:09 GMT, Andrew John Hughes wrote: >> The new test added as part of the >> [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot >> trigger that bug and pass w/ and w/o fix. >> >> An updated test validates the "default" case when the >>

RFR: 8285523: The test for JDK-8285445 can be improved

2022-04-24 Thread Sergey Bylokhov
The new test added as part of the [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot trigger that bug and pass w/ and w/o fix. An updated test validates the "default" case when the `jdk.io.File.enableADS` property is not set, in this case the ADS should be

Re: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2]

2022-03-08 Thread Sergey Bylokhov
On Tue, 8 Mar 2022 13:37:44 GMT, Alexey Ivanov wrote: >> ??? You want to check and cleanup if NewStringUTF fails. You only want to >> call SetObjectElementArray if NewStringUTF succeeds. > > Can `SetObjectElementArray` raise an exception? > The index is within the array length and we store a

Re: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig()

2022-03-08 Thread Sergey Bylokhov
On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes a potential memory leak that > exception return fails to release allocated `cacheDirs` > > Test: > > - [x] jdk_desktop on Linux x86_64 src/java.desktop/unix/native/common/awt/fontpath.c line 938:

Re: RFR: JDK-8280534: Enable compile-time doclint reference checking

2022-01-26 Thread Sergey Bylokhov
On Wed, 26 Jan 2022 20:05:07 GMT, Joe Darcy wrote: > The changes in this PR on top of the out-for-review changes in > https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint > checking to be enabled in all JDK modules. > > Typically, a @SuppressWarnings("doclint:refernce")

Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build

2022-01-23 Thread Sergey Bylokhov
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7189

Re: RFR: 8280010: Remove double buffering of InputStream for Properties.load

2022-01-14 Thread Sergey Bylokhov
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. Marked as reviewed by serb (Reviewer). - PR:

Re: RFR: 8280010: Remove double buffering of InputStream for Properties.load

2022-01-14 Thread Sergey Bylokhov
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. The code change looks fine, but can you please check the actual

Integrated: 8279134: Fix Amazon copyright in various files

2021-12-26 Thread Sergey Bylokhov
On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov wrote: > This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094 > > Currently, some of the files in the OpenJDK repo have Amazon copyright > notices which are all slightly different and do not conform to Amazons

Re: RFR: 8279134: Fix Amazon copyright in various files [v2]

2021-12-23 Thread Sergey Bylokhov
ionally without copyright > year): > > "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." > > @simonis @phohensee Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated

RFR: 8279134: Fix Amazon copyright in various files

2021-12-22 Thread Sergey Bylokhov
This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094 Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging [v2]

2021-12-09 Thread Sergey Bylokhov
uest to delete the > usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge bran

Re: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation

2021-12-03 Thread Sergey Bylokhov
On Thu, 2 Dec 2021 10:55:57 GMT, Andrew Leonard wrote: > This is the case at Adoptium for example, which uses the Mozilla trusted CA > certs. But they didn't think skipping this test was too strong a step? For example validation of the certs expiration is quite useful. I tried to update the

Re: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation

2021-12-01 Thread Sergey Bylokhov
On Wed, 1 Dec 2021 18:30:06 GMT, Andrew Leonard wrote: > Addition of a configure option --with-cacerts-src='user cacerts folder' to > allow developers to specify their own cacerts PEM folder for generation of > the cacerts store using the deterministic openjdk GenerateCacerts tool. > >

Integrated: 8277087: ZipException: zip END header not found at ZipFile#Source.findEND

2021-11-23 Thread Sergey Bylokhov
On Sat, 13 Nov 2021 23:16:22 GMT, Sergey Bylokhov wrote: > The ZipOutputStream class may create bogus zip data which cannot be opened by > the ZipFile. The root cause is how the comment field is stored by the > ZipOutputStream. According to the zip specification, the comment fie

Re: RFR: 8277087: ZipException: zip END header not found at ZipFile#Source.findEND [v2]

2021-11-19 Thread Sergey Bylokhov
On Wed, 17 Nov 2021 10:34:52 GMT, Sergey Bylokhov wrote: >>> Yes it would be nice to clarify that a null is accepted by setComment. When >>> null is specified, the comment length is written as 0 >> >> @mrserb Are you taking the spec clarification or should we

Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal

2021-11-19 Thread Sergey Bylokhov
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java > API" portion of JEP 421 ("Deprecate Finalization for Removal") for code > review. > > This change makes the indicated deprecations, and updates the API

Re: RFR: 8277087: ZipException: zip END header not found at ZipFile#Source.findEND [v2]

2021-11-17 Thread Sergey Bylokhov
On Wed, 17 Nov 2021 18:48:00 GMT, Lance Andersen wrote: > Sorry if my point was not clear. I would prefer to have 1 test to exercise a > Zip file comment vs have tests in multiple areas. Expanding the existing test > in this case keeps the primary coverage in one location and makes it easier

Re: RFR: 8277087: ZipException: zip END header not found at ZipFile#Source.findEND [v2]

2021-11-17 Thread Sergey Bylokhov
On Wed, 17 Nov 2021 12:08:37 GMT, Lance Andersen wrote: > There appears to be a similar test, > open/test/jdk/java/util/zip/ZipFile/Comment.java, I think we probably want to > fold your changes into the existing test and possibly convert to use TestNG. I know that test, and I explicitly

Re: RFR: 8277087: ZipException: zip END header not found at ZipFile#Source.findEND [v2]

2021-11-17 Thread Sergey Bylokhov
On Wed, 17 Nov 2021 09:59:43 GMT, Alan Bateman wrote: >> ZipEntry::setComment indicates that the comment will be truncated if needed >> and ZipOutputStream takes care of this. >> >> Perhaps writeEND() should also be updated to something like: >> `writeBytes(comment, 0,

Re: RFR: 8277087: ZipException: zip END header not found at ZipFile#Source.findEND [v2]

2021-11-15 Thread Sergey Bylokhov
cified in the method/class/package so we are free > here to implement it in any way, any thoughts/suggestions on which is better? Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Update EmptyComment.java - Changes: - a

Re: RFR: 8277087: ZipException: zip END header not found at ZipFile#Source.findEND [v2]

2021-11-15 Thread Sergey Bylokhov
On Sun, 14 Nov 2021 16:14:54 GMT, Martin Buchholz wrote: >> Sergey Bylokhov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update EmptyComment.java > > test/jdk/java/util/zip/ZipOutputStream/Empty

Re: RFR: 8277087: ZipException: zip END header not found at ZipFile#Source.findEND [v2]

2021-11-15 Thread Sergey Bylokhov
On Sun, 14 Nov 2021 14:44:08 GMT, Lance Andersen wrote: >> Sergey Bylokhov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update EmptyComment.java > > test/jdk/java/util/zip/ZipOutputStream/Empty

RFR: 8277087: ZipException: zip END header not found at ZipFile#Source.findEND

2021-11-13 Thread Sergey Bylokhov
The ZipOutputStream class may create bogus zip data which cannot be opened by the ZipFile. The root cause is how the comment field is stored by the ZipOutputStream. According to the zip specification, the comment field should not be longer than 0x bytes, and we try to validate the length of

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-11-07 Thread Sergey Bylokhov
On Fri, 29 Oct 2021 16:32:43 GMT, Mandy Chung wrote: > The change looks okay. My suggestion is to get 1-6 all ready to push around > the same time. It's okay to have separate JBS issues and PRs. ok, I'll continue to work using the plan from the description. - PR:

Re: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException

2021-10-29 Thread Sergey Bylokhov
On Thu, 28 Oct 2021 14:30:20 GMT, Alan Bateman wrote: >> Could you please review the 8262297 bug fixes? >> >> In this case, ImageIO.write() should throw java.io.IOException rather than >> java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and >> wrapped in IIOException

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-10-28 Thread Sergey Bylokhov
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > At the time Java supported applets and webstart, a special mechanism for > launching various applications in one JVM was used to reduce memory usage and > each application was isolated from each other. > >

Re: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec

2021-10-25 Thread Sergey Bylokhov
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote: > It looks like we cannot use `Long.hashCode(long)` for > `java.rmi.server.ObjID.hashCode()` due to specification: > https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). I think this one was

Re: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec

2021-10-25 Thread Sergey Bylokhov
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote: > It looks like we cannot use `Long.hashCode(long)` for > `java.rmi.server.ObjID.hashCode()` due to specification: > https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). Just a suggestion, it

Re: RFR: 8270490: Charset.forName() taking fallback default value [v4]

2021-10-25 Thread Sergey Bylokhov
On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to >> `Charset.forName()` was suggested >> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This >> PR is to implement the proposal. A CSR is

Re: RFR: 8275170: Some jtreg sound tests should be marked headful

2021-10-24 Thread Sergey Bylokhov
On Sun, 24 Oct 2021 16:45:15 GMT, Phil Race wrote: > This makes the tests eligible to be run on headful systems. In practice it > seems like ONLY headful systems actually have the sound devices. The sound > keyword isn't understood by anything yet, so adding headful is the only way > we have

Re: RFR: 8270490: Charset.forName() taking fallback default value [v3]

2021-10-23 Thread Sergey Bylokhov
On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to >> `Charset.forName()` was suggested >> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This >> PR is to implement the proposal. A CSR is

Re: RFR: 8270490: Charset.forName() taking fallback default value [v3]

2021-10-22 Thread Sergey Bylokhov
On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to >> `Charset.forName()` was suggested >> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This >> PR is to implement the proposal. A CSR is

Re: RFR: 8275170: Some jtreg sound tests should be marked headful

2021-10-22 Thread Sergey Bylokhov
On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race wrote: > This fix adds "headful sound" keywords to a number of javax/sound jtreg tests > > The jtreg javax.sound tests are written in such a way that if a needed audio > device > or other platform resource is not available, they just exit with a

Re: RFR: 8270490: Charset.forName() taking fallback default value [v2]

2021-10-21 Thread Sergey Bylokhov
On Thu, 21 Oct 2021 16:03:29 GMT, Naoto Sato wrote: >> Apparently `IllegalCharsetNameException` or `IllegalArgumentException` could >> still be thrown - so removing the `try-catch` would be a change of behaviour >> in those cases. It all depends on whether there is a chance that these >>

Re: RFR: 8270490: Charset.forName() taking fallback default value [v2]

2021-10-20 Thread Sergey Bylokhov
On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to >> `Charset.forName()` was suggested >> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This >> PR is to implement the proposal. A CSR is

Re: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v4]

2021-10-12 Thread Sergey Bylokhov
On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов wrote: >> In some JDK classes there's still the following hashCode() implementation: >> >> long objNum; >> >> public int hashCode() { >> return (int) objNum; >> } >> >> This outdated expression should be replaced with Long.hashCode(long) as

Re: RFR: 8177814: jdk/editpad is not in jdk TEST.groups

2021-10-12 Thread Sergey Bylokhov
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote: > @prrace notices this here: > https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think > it is the already open issue that this patch is fixing. While the original > patch added the test in `jdk_other`, Phil

Re: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE

2021-10-10 Thread Sergey Bylokhov
On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov wrote: > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 240: > 238: * OutOfMemoryError: Requested array size exceeds VM limit > 239: */ > 240:

Re: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v5]

2021-10-05 Thread Sergey Bylokhov
On Tue, 5 Oct 2021 00:25:41 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set >> the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety >> issue described in

Re: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v4]

2021-10-04 Thread Sergey Bylokhov
On Fri, 1 Oct 2021 21:10:27 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set >> the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety >> issue described in

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-09-29 Thread Sergey Bylokhov
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > At the time Java supported applets and webstart, a special mechanism for > launching various applications in one JVM was used to reduce memory usage and > each application was isolated from each other. > >

Re: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v2]

2021-09-28 Thread Sergey Bylokhov
On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set >> the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety >> issue described in

Re: RFR: 8177814: jdk/editpad is not in jdk TEST.groups

2021-09-23 Thread Sergey Bylokhov
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote: > @prrace notices this here: > https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think > it is the already open issue that this patch is fixing. While the original > patch added the test in `jdk_other`, Phil

Re: RFR: 8273314: Add tier4 test groups [v4]

2021-09-17 Thread Sergey Bylokhov
On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, >> @iignatev suggested to create tier4 groups that capture all tests not in >> tiers{1,2,3}. >> >> Caveats: >> - I excluded `applications` from `hotspot:tier4`,

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-09-16 Thread Sergey Bylokhov
On Mon, 6 Sep 2021 09:39:58 GMT, Alan Bateman wrote: > No objection to removing this legacy/unused code but I think it would be > useful to useful to have the JBS issue or the PR summary provide a bit more > context. As I see it, this is just one piece of the overall cleanup and I > assume

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-09-09 Thread Sergey Bylokhov
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" > via an AppContext to support "applet logging isolation". The AppContext class > became useless since the plug

Re: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac

2021-09-09 Thread Sergey Bylokhov
On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 Is it for jdk17 or for jdk17u? - PR: https://git.openjdk.java.net/jdk17/pull/306

Re: RFR: 8273314: Add tier4 test groups

2021-09-06 Thread Sergey Bylokhov
On Sat, 4 Sep 2021 02:51:50 GMT, Sergey Bylokhov wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, >> @iignatev suggested to create tier4 groups that capture all tests not in >> tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` bec

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-09-06 Thread Sergey Bylokhov
On Mon, 6 Sep 2021 09:39:58 GMT, Alan Bateman wrote: > As I see it, this is just one piece of the overall cleanup and I assume there > are more substantive changes to the java.desktop module coming, is that right? Yes, you are right. - PR:

Re: RFR: 8273314: Add tier4 test groups

2021-09-03 Thread Sergey Bylokhov
On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev wrote: > During the review of JDK-8272914 that added hotspot:tier{2,3} groups, > @iignatev suggested to create tier4 groups that capture all tests not in > tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they > take 10+

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-09-03 Thread Sergey Bylokhov
On Thu, 2 Sep 2021 09:59:51 GMT, Daniel Fuchs wrote: >> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" >> via an AppContext to support "applet logging isolation". The AppContext >> class became useless since the plugin and webstart are no longer supported >> and

Re: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName)

2021-09-03 Thread Sergey Bylokhov
On Fri, 3 Sep 2021 17:37:08 GMT, Sergey Bylokhov wrote: >> Current implementation looks like this: >> >> public byte[] getBytes(String charsetName) >> throws UnsupportedEncodingException { >> if (charsetName == null) throw new NullPointerExc

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-09-03 Thread Sergey Bylokhov
On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race wrote: > Perhaps this isn't the change that requires the CSR but it then leaves an > inconsistent state where desktop supports AppContext still but other modules > don't ... Even java.desktop does not support it fully, since for a couple of years

Re: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName)

2021-09-03 Thread Sergey Bylokhov
On Fri, 3 Sep 2021 13:22:54 GMT, Сергей Цыпанов wrote: > Current implementation looks like this: > > public byte[] getBytes(String charsetName) > throws UnsupportedEncodingException { > if (charsetName == null) throw new NullPointerException(); > return

RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-09-02 Thread Sergey Bylokhov
The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. This is the request to delete the usage of

Re: RFR: 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302

2021-08-31 Thread Sergey Bylokhov
On Tue, 31 Aug 2021 09:40:14 GMT, xpbob wrote: > 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5315

Re: RFR: 8271302: Regex Test Refresh [v5]

2021-08-31 Thread Sergey Bylokhov
On Mon, 30 Aug 2021 15:52:05 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional > commit since the last revision: > > Removing some notes re JUnit5 Looks like it was missed that the test fails oi a github

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

2021-08-24 Thread Sergey Bylokhov
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. The changes in the src/java.desktop/ looks fine. Filed: https://bugs.openjdk.java.net/browse/JDK-8272863 - Marked as reviewed by

Re: RFR: JDK-8272639: jpackaged applications using microphone on mac [v2]

2021-08-23 Thread Sergey Bylokhov
On Mon, 23 Aug 2021 14:34:52 GMT, Andy Herrick wrote: >> JDK-8272639: jpackaged applications using microphone on mac > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8272639: jpackaged applications using microphone on

RFR: 8272805: Avoid looking up standard charsets

2021-08-22 Thread Sergey Bylokhov
This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. See https://github.com/openjdk/jdk/pull/5063 and https://github.com/openjdk/jdk/pull/4951 In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more

Re: RFR: JDK-8272639: jpackaged applications using microphone on mac

2021-08-19 Thread Sergey Bylokhov
On Thu, 19 Aug 2021 14:12:00 GMT, Andy Herrick wrote: > JDK-8272639: jpackaged applications using microphone on mac src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/Info-lite.plist.template line 37: > 35: true > 36: NSMicrophoneUsageDescription > 37: The application is

Integrated: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Sergey Bylokhov
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: &

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-10 Thread Sergey Bylokhov
On Tue, 10 Aug 2021 09:18:39 GMT, Alan Bateman wrote: > It would be useful to get up to date performance data on using Charset vs. > charset name. At least historically, the charset name versions were faster > (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)). The code in

RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-09 Thread Sergey Bylokhov
This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more efficiently(up to x20 time faster)

Re: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

2021-08-01 Thread Sergey Bylokhov
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 shorter call `T[] >

Re: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

2021-07-26 Thread Sergey Bylokhov
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 shorter call `T[] >

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM [v3]

2021-03-18 Thread Sergey Bylokhov
On Wed, 17 Mar 2021 00:57:24 GMT, Henry Jen wrote: >> This patch ensure launcher won't crash JVM for the new static Methods from >> local/anonymous class on MacOS. >> >> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug >> when the launcher trying to grab class name to

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM [v2]

2021-03-16 Thread Sergey Bylokhov
On Tue, 16 Mar 2021 17:39:34 GMT, Henry Jen wrote: >> test/jdk/tools/launcher/8261785/CrashTheJVM.java line 1: >> >>> 1: import java.io.IOException; >> >> Copyright? > > This file is mostly based on the bug report as I just adjust static keyword > to make sure we cover different cases, thus I

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM

2021-03-16 Thread Sergey Bylokhov
On Tue, 16 Mar 2021 01:55:49 GMT, Sergey Bylokhov wrote: >> This patch ensure launcher won't crash JVM for the new static Methods from >> local/anonymous class on MacOS. >> >> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug >> when the

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM

2021-03-15 Thread Sergey Bylokhov
On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote: > This patch ensure launcher won't crash JVM for the new static Methods from > local/anonymous class on MacOS. > > As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug > when the launcher trying to grab class name to be

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM

2021-03-15 Thread Sergey Bylokhov
On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote: > This patch ensure launcher won't crash JVM for the new static Methods from > local/anonymous class on MacOS. > > As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug > when the launcher trying to grab class name to be

Re: RFR: 8263560: Remove needless wrapping with BufferedInputStream [v6]

2021-03-15 Thread Sergey Bylokhov
On Mon, 15 Mar 2021 18:04:26 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 related to

Re: RFR: 8263560: Remove needless wrapping with BufferedInputStream [v3]

2021-03-14 Thread Sergey Bylokhov
On Sun, 14 Mar 2021 19:35:25 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 related to

Re: RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category) [v2]

2021-03-06 Thread Sergey Bylokhov
On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad wrote: >> This patch refactors Locale.getDefault(Category) so that the volatile field >> holding the Locale is typically only read once. This has a small performance >> advantage, and might be more robust if initialization is racy. > > Claes

Re: RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category) [v2]

2021-03-06 Thread Sergey Bylokhov
On Sat, 6 Mar 2021 13:34:14 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/util/Locale.java line 946: >> >>> 944: Locale loc = defaultDisplayLocale; // volatile read >>> 945: if (loc == null) { >>> 946: loc = getDisplayLocale(); >> >>

Re: RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category) [v2]

2021-03-05 Thread Sergey Bylokhov
On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad wrote: >> This patch refactors Locale.getDefault(Category) so that the volatile field >> holding the Locale is typically only read once. This has a small performance >> advantage, and might be more robust if initialization is racy. > > Claes

Integrated: 8261010: Delete the Netbeans "default" license header

2021-02-03 Thread Sergey Bylokhov
On Wed, 3 Feb 2021 04:01:51 GMT, Sergey Bylokhov wrote: > Trivial cleanup, the "default" license header is removed in a few components. This pull request has now been integrated. Changeset: f279ff9d Author:Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/f

RFR: 8261010: Delete the Netbeans "default" license header

2021-02-02 Thread Sergey Bylokhov
Trivial cleanup, the "default" license header is removed in a few components. - Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/2368/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2368=00 Issue:

Re: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo

2020-12-20 Thread Sergey Bylokhov
On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race 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:

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Sergey Bylokhov
On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman wrote: >> This change terminally deprecates the following methods defined by >> java.lang.ThreadGroup >> >> - stop >> - destroy >> - isDestroyed >> - setDaemon >> - isDaemon >> >> The stop method has been deprecated since=1.2 because it is

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-19 Thread Sergey Bylokhov
On Thu, 19 Nov 2020 18:51:50 GMT, Sergey Bylokhov wrote: >> This change terminally deprecates the following methods defined by >> java.lang.ThreadGroup >> >> - stop >> - destroy >> - isDestroyed >> - setDaemon >> - isDaemon >> &g

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-19 Thread Sergey Bylokhov
On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman wrote: > This change terminally deprecates the following methods defined by > java.lang.ThreadGroup > > - stop > - destroy > - isDestroyed > - setDaemon > - isDaemon > > The stop method has been deprecated since=1.2 because it is inherently

Re: RFR: 8246739: InputStream.skipNBytes could be implemented more efficiently

2020-11-19 Thread Sergey Bylokhov
On Thu, 19 Nov 2020 19:29:43 GMT, Brian Burkhalter wrote: > Please review this modification of `java.io.InputStream.skipNBytes(long)` to > improve its performance when `skip(long)` skips fewer than the requested > number of bytes. In the current implementation, `skip(long)` is invoked once >

Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v3]

2020-11-13 Thread Sergey Bylokhov
On Fri, 13 Nov 2020 18:20:37 GMT, Kevin Rushforth wrote: >> Andy Herrick has updated the pull request incrementally with one additional >> commit since the last revision: >> >> JDK-8189198: Add "forRemoval = true" to Applet APIs > >

Re: RFR: 8255989: Remove explicitly unascribed authorship from Java source files

2020-11-07 Thread Sergey Bylokhov
On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo wrote: > This PR proposes to remove > 1. JavaDoc `@author` tags with unclear semantics: `@author > unascribed|unattributed|unknown` > 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters Marked as reviewed by serb

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v20]

2020-11-02 Thread Sergey Bylokhov
On Mon, 2 Nov 2020 11:59:09 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the third incubation round >> of the foreign memory access API incubation (see JEP 393 [1]). This >> iteration focus on improving the usability of the API in 3 main ways: >> >> *

Re: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic* objects [v2]

2020-10-28 Thread Sergey Bylokhov
On Wed, 28 Oct 2020 08:40:02 GMT, Сергей Цыпанов wrote: >> client changes are fine > > 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.

Re: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic* objects

2020-10-23 Thread Sergey Bylokhov
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 with `new >

Integrated: 8255043: Incorrectly styled copyright text

2020-10-20 Thread Sergey Bylokhov
On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov wrote: > In some files, the copyright text is styled as a JavaDoc comment. > Most of the affected files are tests, only one product file is affected: > src/java.sql/share/classes/javax/sql/package-info.java > > The ch

RFR: 8255043: Incorrectly styled copyright text

2020-10-20 Thread Sergey Bylokhov
In some files, the copyright text is styled as a JavaDoc comment. Most of the affected files are tests, only one product file is affected: src/java.sql/share/classes/javax/sql/package-info.java The chenge is trivial: - /** + /* * Copyright (c) - Commit messages: - Initial fix

RFR: 8253606: Need to add missed constructor to the SwingEventMonitor

2020-09-24 Thread Sergey Bylokhov
The javadoc for this class was added, but the constructor itsef is missed.. - Commit messages: - Update SwingEventMonitor.java Changes: https://git.openjdk.java.net/jdk/pull/340/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=340=00 Issue:

Re: RFR: 8252999: replace all String.equals("") usages with String.isEmpty()

2020-09-10 Thread Sergey Bylokhov
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could > be found > > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

2020-02-11 Thread Sergey Bylokhov
I there are no objections I'll push the fix to JDK/client. On 12/11/19 7:29 pm, Igor Ignatyev wrote: Hi Sergey, overall looks good to me. a question about linux, is there an alternative to gnome-screenshot for DEs other than GNOME? -- Igor On Dec 11, 2019, at 1:00 AM, Sergey Bylokhov

Re: RFR: 8236075: Minor bootstrap improvements

2020-01-20 Thread Sergey Bylokhov
Hi Claes, How did you measure this performance improvement? On 1/20/20 7:54 am, Claes Redestad wrote: Hi, some minor cleanups and enhancements in and around java.lang.ClassLoader which add up to a small startup improvement: - Remove use of Vector/Hashtable from ClassLoader, along with a few

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

2020-01-06 Thread Sergey Bylokhov
via "make test", and it could easily be enabled in mach5 for personal jobs(I do this time to time) -phil. On 12/30/19, 11:33 AM, Sergey Bylokhov wrote: On 12/23/19 9:15 pm, Phil Race wrote: I am not sure what the right mailing list(s) are for this change. It definitely isn't a core-l

Re: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18

2020-01-02 Thread Sergey Bylokhov
I guess it is too late to fix it, will need to update the files at the end of 2020. On 1/2/20 10:57 am, Erik Joelsson wrote: Build files look good. /Erik On 2019-12-24 19:22, Sergey Bylokhov wrote: Hello. Here is an updated version:   Bug: https://bugs.openjdk.java.net/browse/JDK-8235975

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

2019-12-30 Thread Sergey Bylokhov
S And it does not spend much resources compared to current handlers. Also why exclude Windows ? No easy way to get the screenshot ? There is no command-line program that can take a screenshot on windows by default -phil. On 12/11/19 1:00 AM, Sergey Bylokhov wrote: Hello. Please review th

  1   2   >