[11] Review Request: 8205537 Drop of sun.applet package

2018-07-02 Thread Sergey Bylokhov
Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ sun.applet is an internal package contained some code related to implementation of applets and appletviewer. Some of its classes were

Re: [11] Review Request: 8205537 Drop of sun.applet package

2018-07-02 Thread Sergey Bylokhov
I can argue that this is not p2 as related JDK-8201446, but it is definitely not p4. On 02/07/2018 09:30, Phil Race wrote: It is not necessary and I reject that it is a P3. Let's leave it for 12. -phil. On 07/02/2018 09:24 AM, Sergey Bylokhov wrote: I think it is a good thing to drop

Re: [11] Review Request: 8205537 Drop of sun.applet package

2018-07-02 Thread Sergey Bylokhov
it for 11, but will consider it for 12. -phil. On 7/2/2018 6:36 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ sun.applet is an internal package contained some

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).

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: 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 >

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: 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: 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: 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: 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: 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,… [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: 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: >> >> *

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

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: 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: 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: 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: 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: 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 [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: 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

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-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

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

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: 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: 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

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

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

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: 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: 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: 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: 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: 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-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

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: 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

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[] >

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: 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: 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: 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: 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: 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: 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: 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: 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 [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: 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: 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: 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: 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

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

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

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-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-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 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: 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-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: 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

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
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

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: 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 [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: 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: 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: 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: 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: 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: 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. > >

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: 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: 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: 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: 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: 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: 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

Re: [8] Review Request: 8027696 Incorrect copyright header in the tests

2013-11-02 Thread Sergey Bylokhov
On 02.11.2013 15:37, Alan Bateman wrote: On 01/11/2013 11:18, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 8. Most of tests in the sound area, and some tests in the client, java.lang, security, jmx etc has incorrect copyright. According to the http://openjdk.java.net/faq GPL v2

Re: [8] Review Request: 8027696 Incorrect copyright header in the tests

2013-11-05 Thread Sergey Bylokhov
Hello, Updated version: http://cr.openjdk.java.net/~serb/8027696/webrev.01/ Dates and spaces were fixed. On 02.11.2013 15:37, Alan Bateman wrote: On 01/11/2013 11:18, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 8. Most of tests in the sound area, and some tests in the client

Re: [8] Review Request: 8027696 Incorrect copyright header in the tests

2013-11-07 Thread Sergey Bylokhov
On 07.11.2013 15:22, Alan Bateman wrote: Thanks Sergey, I sampled a few and they look correct. The only thing is that I'm not sure about is test/Makefile, it's just not clear whether which header this should have. I can skip it this time. -- Best regards, Sergey.

Re: [8] Review Request: 8027696 Incorrect copyright header in the tests

2013-11-11 Thread Sergey Bylokhov
Hello. I'll push the changes, if there are no new objections. On 07.11.2013 17:46, Sergey Bylokhov wrote: On 07.11.2013 15:22, Alan Bateman wrote: Thanks Sergey, I sampled a few and they look correct. The only thing is that I'm not sure about is test/Makefile, it's just not clear whether

Re: AWT Dev RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

2013-11-26 Thread Sergey Bylokhov
has been already answered by Iris (thanks Iris). Thank you and best regards, Volker On Tuesday, November 26, 2013, Sergey Bylokhov wrote: On 26.11.2013 21:03, Alan Bateman wrote: On 26/11/2013 16:23, Volker Simonis wrote: Hi, thanks to everybody

Re: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9

2014-01-23 Thread Sergey Bylokhov
On 23.01.2014 3:53, Vladimir Kozlov wrote: I need help. I am trying to do control build in JPRT after I merged latest jdk9 source: http://hg.openjdk.java.net/jdk9/jdk9 Looks like the problem is that 8032348 is not pushed to the master workspace of jdk9, but the bootjdk have this fix. to

  1   2   >