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

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 plugin and webstart are no longer supported and > remo

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

On Tue, 24 Aug 2021 20:21:52 GMT, Andrey Turbanov wrote: >> 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 us

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

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. java/net and sun/net changes LGTM - Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` >> annotation that covers more than 50KB of code. The big annotation is often >> quite faraway from the actual deprecated API usage it is suppressing, and >> with

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

On Fri, 21 May 2021 14:00:39 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` >> annotation that covers more than 50KB of code. The big annotation is often >> quite faraway from the actual deprecated API usage it is suppressing, and >> with

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e38

Re: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP > 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming > `disallow`, tests calling `System.setSecurityManager()` need > `-Djava.secu

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

On Wed, 28 Oct 2020 08:56:05 GMT, Сергей Цыпанов wrote: >> FYI it is better to use merge, instead of rebase+force push. Rebase breaks >> history and all existed code comments. > > @mrserb thanks for pointing this out! Thanks for updating with latest master changes Sergey! My tests were all gre

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

On Fri, 23 Oct 2020 09:14:48 GMT, Daniel Fuchs wrote: >> The changes in src/java.desktop looks fine. > > Changes to `java.logging` and `java.net.http` also look good to me. Hi Sergey, I'll give it some testing and sponsor it next week unless someone else steps up. best r

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

On Fri, 23 Oct 2020 08:15:00 GMT, Sergey Bylokhov 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 >> AtomicI

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

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

Re: RFR[8250855]: 'Address reliance on default constructors in the Java 2D APIs'

On 17/08/2020 12:16, Lance Andersen wrote: The description for almost all of the constructors indicate: Constructor for subclasses to call —— Is the above wording used elsewhere in the JDK? Not sure I like it, I might suggest a little wordsmithing As far as I know that's what Joe

Re: [13] Review Request: 8220134 Cleanup the code in java.base which take care about multiple AppContext

On 19/04/2019 16:46, Alan Bateman wrote: On 18/04/2019 23:41, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8220134 Fix: http://cr.openjdk.java.net/~serb/8220134/webrev.00 The AppContext class was used as a kind of "sandbox" in ca

Re: RFR(M) : 8210039 : move OSInfo to top level testlibrary

Hi Igor, Nit: You could have introduced a private static String getProperty(String name) { return AccessController.doP } in Platform.java to avoid the long lines. Otherwise looks good to me too! best regards, -- daniel On 31/08/2018 19:42, Igor Ignatyev wrote: Alan, Chris, thanks f

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

Hi Paul, I looked at -management and the changes there look good. There is just some two spaces vs four space formatting in line 99

RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup")

Adding awt-dev... The change looks okay to me but I would suggest sending to awt-dev so that the folks that maintain this area know about it. On the test then does initializing SunToolkit cause AWT to be initialized? I just wonder if this test will run headless. -Alan. Hi, Please find be

Re: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup")

Hi David, On 10/15/13 9:38 AM, David Holmes wrote: On 15/10/2013 5:19 AM, Daniel Fuchs wrote: Adding awt-dev... The change looks okay to me but I would suggest sending to awt-dev so that the folks that maintain this area know about it. On the test then does initializing SunToolkit cause AWT