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

On Mon, 17 May 2021 18:23:41 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/576161d15423f58281e384174d28

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: 8255989: Remove explicitly unascribed authorship from Java source files

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 mchung (Reviewer

Re: RFR: 8227587: Add internal privileged System.loadLibrary

wrap the call with doPriv; otherwise, just call the shared secret loadLibrary method. Then we can investigate in the future to refactor the native library loading implementation to jdk.internal.loader. what do you think? Mandy On 7/12/19 8:25 AM, Mandy Chung wrote: Claes, Thanks for exploring

Re: RFR: 8227587: Add internal privileged System.loadLibrary

Claes, Thanks for exploring this.  I would like to see if we can avoid introducing an internal @CS method (keep @CSM only for public APIs will help security analysis). There are other alternatives to improve the footprint performance. One idea is java.base and java.desktop each has its own util

Re: RFR; 8211031: Remove un-needed qualified export to java.desktop from java.base on macos

Removal of module-info.java.extra is good. Mandy On 9/21/18 1:13 PM, Philip Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8211031 webrev: http://cr.openjdk.java.net/~prr/8211031/ Removing some obsolete code which is the reason for a qualified export from java.base to java.desktop.

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

On 6/15/18 12:31 AM, Prasanta Sadhukhan wrote: Webrev to add @since 11 to jdk.swing.interop classes (only difference from .14) http://cr.openjdk.java.net/~psadhukhan/fxswing.15/ +1 Mandy

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

Great! Thanks Prasanta. Mandy On 6/15/18 5:42 AM, Prasanta Sadhukhan wrote: I confirm jdk.unsupported.desktop is not present in doc build. Regards Prasanta

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

ve it has been verified that it is excluded from the docs build .. right Prasanta ? -phil On 06/14/2018 01:26 PM, mandy chung wrote: I reviewed the module-info.java change. @since 12 is missing in jdk.unsupported.desktop module-info.java Otherwise it's fine. Does the docs bui

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

On 6/14/18 1:29 PM, Phil Race wrote: you surely mean @since 11 Oops typo. Yes @since 11 Mandy

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

I reviewed the module-info.java change. @since 12 is missing in jdk.unsupported.desktop module-info.java Otherwise it's fine. Does the docs build exclude jdk.unsupported.desktop? You might have confirmed that that I missed. Mandy On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote: Hi Phil, Al

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

On 5/9/18 7:48 AM, Alan Bateman wrote: On 09/05/2018 15:42, Philip Race wrote: : Qn. to Mandy & Alan : it seems there is no need to mention this module in make/common/Modules.gmk in order to get it built, but is there any advantage in doing so ? I mean without it, there is no conscious listi

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

On 5/7/18 2:26 AM, Prasanta Sadhukhan wrote: Modified webrev to use InteropProvider http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ This version looks good.   InteropProviderImpl name is okay with me. Mandy

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

I skimmed through the sources.  It's good to see that this patch is straight forward.  A couple of comments: jdk.unsupported.desktop is defined to the application class loader which I think it's fine as FX modules are defined to the same class loader. I expect src/java.base/share/lib/security/de

Re: [10] Review Request: 8189656 The Windows L&F should be moved out from the shared folder

jconsole checks if it uses windows LAF ( com.sun.java.swing.plaf.windows.WindowsLookAndFeel class.  And also reflectively access the fields in com.sun.java.swing.plaf.windows.TMSchema$Part to workaround some issue. Mandy On 11/28/17 1:38 PM, Phil Race wrote: I see this opens was moved to plat

Re: [9] Review Request: 8181894 java.desktop module documentation has links to technotes

It’s in my build: docs/specs/jar/jar.html Do you pull in the up-to-date changeset? Mandy > On Jun 16, 2017, at 8:11 PM, Sergey Bylokhov > wrote: > > Hi, Mandy. > I rechecked this fix on top of JDK-8150681, and found that the jar/jar.html > was not copied to the "/images/docs/specs/« but

Re: [9] Review Request: 8181894 java.desktop module documentation has links to technotes

> On Jun 16, 2017, at 9:49 AM, Sergey Bylokhov > wrote: > > Hello, > Please review the fix for jdk9-dev. > > A few types of links were fixed: > - The fix for JDK-8178412 missed some links to IMF. > - The links to jar.html#service_provider were changed to {@link > ServiceLoader} > - The lin

Re: RFR: 8173409: make setMixingCutoutShape public and remove jdk.desktop

> On Jan 27, 2017, at 10:30 AM, Phil Race wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173409 > > Webrev: http://cr.openjdk.java.net/~prr/8173409/ > > The part that removes of jdk.deskt

Re: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

>>> On Dec 22, 2016, at 1:33 AM, Semyon Sadetsky >> <mailto:semyon.sadet...@oracle.com>> wrote: >>> >>> >>> >>> >>> On 20.12.2016 19:41, Mandy Chung wrote: >>>> >>>>> On Dec 20, 2016, at 8:24 AM, Sergey

Re: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

> On Dec 22, 2016, at 1:33 AM, Semyon Sadetsky > wrote: > > > > On 20.12.2016 19:41, Mandy Chung wrote: >> >>> On Dec 20, 2016, at 8:24 AM, Sergey Bylokhov >> <mailto:sergey.bylok...@oracle.com>> wrote: >>> >>>>>

Re: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

> On Dec 20, 2016, at 8:24 AM, Sergey Bylokhov > wrote: > If this private data can be loaded to the UIDefaults or to other class then it will be read anyway. Are the Swing/AWT properties files content really secret? >>> My point is that there are no secrets, but the bug descrip

Re: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

> On Dec 19, 2016, at 5:59 AM, Sergey Bylokhov > wrote: > >> Sergey, >> >> I suggest to update the spec of UIDefaults::addResourceBundle to: >> >> Adds a resource bundle to the list of resource bundles that are >> searched for localized values. Resource bundles are searched in >> the revers

Re: RFR: 8171363: [PIT] Four Windows-specific tests fail with InaccessibleObjectException when calling Field.setAccessible()

> On Dec 16, 2016, at 3:27 PM, Phil Race wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171363 > Webrev: http://cr.openjdk.java.net/~prr/8171363/ +1 Mandy

Re: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

> On Dec 15, 2016, at 10:35 PM, Semyon Sadetsky > wrote: > > On 15.12.2016 13:19, Sergey Bylokhov wrote: > Because addResourceBundle() was modified to «not» allow the users to expose internal resource bundles(for example the users are not able to read content of some random bu

Re: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

> On Nov 30, 2016, at 8:55 AM, Semyon Sadetsky > wrote: > > > > On 30.11.2016 19:34, Sergey Bylokhov wrote: >> On 30.11.16 9:52, Semyon Sadetsky wrote: >>> On 11/28/2016 7:41 PM, Sergey Bylokhov wrote: >>> Hello. Please review the fix for jdk9. This fix improve enc

Re: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Looks okay to me. Mandy > On Nov 28, 2016, at 8:41 AM, Sergey Bylokhov > wrote: > > Hello. > > Please review the fix for jdk9. > > This fix improve encapsulation of java.desktop module. After the fix the > method "UIDefaults::addResourceBundle()" will not be able to register > resource bu

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

> On Oct 31, 2016, at 7:36 AM, Pete Brunet wrote: > > > > On 10/28/16 8:14 PM, Mandy Chung wrote: >>> On Oct 28, 2016, at 1:59 PM, Philip Race wrote: >>> >>> If it is not in the image then there is no point in the file existing. >>> M

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

> On Oct 28, 2016, at 1:59 PM, Philip Race wrote: > > If it is not in the image then there is no point in the file existing. > Maybe this could just be a comment at the top of the include file. > This works for me. Mandy > -phil. > > On 10/28/16, 12:42 PM, Mandy Ch

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

> On Oct 28, 2016, at 11:32 AM, Pete Brunet wrote: > > Hi Mandy, That simplifies things. The new patch is at: > http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.08/ Looks better. I only notice now that the readme.html is in the include directory. That should be in the documentation

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

> On Oct 27, 2016, at 4:31 PM, Pete Brunet wrote: > > I moved the source to > src/jdk.accessibility/windows/native/bridge/src “src” subdirectory is redundant that should be dropped. > and the includes to > src/jdk.accessibility/windows/native/bridge/include Please see the source layout defin

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

> On Oct 27, 2016, at 10:44 AM, Phil Race wrote: > > No, we are definitely shipping those. > Unless of course you think we should stop shipping JNI headers too … > No. I tried to understand what is external interface. I took it that these header files are external interfaces. I reviewed:

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

t; The .h files are unlicensed in the bundle/install so no need? > > On 10/26/16 11:52 PM, Mandy Chung wrote: >> Should the same change be applied to the .h files as well? >> >> Mandy >> >>> On Oct 26, 2016, at 7:24 PM, Pete Brunet wrote: >

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

Should the same change be applied to the .h files as well? Mandy > On Oct 26, 2016, at 7:24 PM, Pete Brunet wrote: > > Please review the latest update at > http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/ > > The change is to AccessBridgeCalls.c. The license has been changed from >

Re: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK

The jconsole change looks fine. I’m including serviceability-dev and bcc core-libs-dev as serviceability-dev is the right mailing list for jconsole change. Mandy > On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov > wrote: > > Hello. > > Please review the fix for jdk9. > > This is request to d

Re: RfR JDK-8055831 Open Source Java Access Bridge

On 3/24/2015 2:36 PM, Pete Brunet wrote: Here's the latest patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ The modules.xml change looks fine. Mandy

Re: Supplemental code review request for JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.*

I reviewed the jconsole change that looks okay to me. Mandy On 7/3/14 12:44 PM, Joe Darcy wrote: Hello, In the course of fixing JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.* http://cr.openjdk.java.net/~darcy/8043550.1/ I encountered a build failure in jconsole due