Re: AWT Dev [OpenJDK 2D-Dev] Review Request for 6879044

Hi Oleg, A better question to ask is who and how the logging information AWT is used for. The AWT team confirms that the AWT loggers are for debugging purpose used by the awt developers. As specified in the Requirements chapter for the Java Logging Spec (JSR-47) [1], the central goal of

Re: AWT Dev [OpenJDK 2D-Dev] Review Request for 6879044

Anthony Petrov wrote: On 09/23/2009 03:41 PM, Alan Bateman wrote: If AWT initialized the loggers lazily, and only did it when the logging is actually enabled (checking for some system property, or whatever other way), would we still be statically linked to the j.u.logging package in case of a

AWT Dev hg: jdk7/awt/jdk: 6907568: java/awt/KeyboardFocusManager.java inproperly merged and lost a changeset

Changeset: 725bf9c81f86 Author:mchung Date: 2009-12-08 09:02 -0800 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/725bf9c81f86 6907568: java/awt/KeyboardFocusManager.java inproperly merged and lost a changeset Summary: Reapply fix for 6879044 in java.awt.KeyboardFocusManager

AWT Dev Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction

7164376 Replace use of sun.security.action.LoadLibraryAction with direct call of System.loadLibrary Webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7164376/webrev.00/ This change is required for jdk modularization. High level summary: it replaces the use of LoadLibraryAction:

Re: AWT Dev Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction

/classes/sun/management/FileSystemImpl.java src/windows/classes/sun/management/FileSystemImpl.java - line-break coding style is different from all others; probably better to be consistent --Sean On 04/26/2012 02:49 PM, Mandy Chung wrote: 7164376 Replace use

Re: AWT Dev Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction

to check all those are still the same. -phil. On 4/26/2012 2:20 PM, Mandy Chung wrote: Thanks, Sean. I have fixed the 3 files per your comment. Mandy On 4/26/2012 1:59 PM, Sean Mullan wrote: Looks fine, just a couple of nits. src/macosx/classes/com/apple/concurrent/LibDispatchNative.java

Re: AWT Dev Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction

PM, Mandy Chung wrote: 7164376 Replace use of sun.security.action.LoadLibraryAction with direct call of System.loadLibrary Webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7164376/webrev.00/ This change is required for jdk modularization. High level summary: it replaces the use

Re: AWT Dev PlatformLogger: isLoggable performance / waste due to HashMapInteger, Level leads to Integer allocations (boxing)

Hi Laurent, Thanks for the contribution. I agree that the map can be replaced with a direct mapping from a int value to Level object and avoid the autoboxing conversion. I have filed a bug to track this and target this for JDK8: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309

Re: AWT Dev Swing Dev sun.awt.X11 logs still using String + (waste)

Peter, Laurent, Peter's idea is a good one to add a couple of convenient methods to take Object parameters that will avoid the creation of array instances. I'd also like to know what variants being used in the jdk to determine the pros and cons of the alternatives (this issue also applies to

Re: AWT Dev Swing Dev sun.awt.X11 logs still using String + (waste)

On 4/9/13 12:37 AM, Laurent Bourgès wrote: Mandy, first I would like to have the given patch applied to OpenJDK 8 (+ JDK7u) as it fixes many problems: - string concatenations - object creations (Object[] or other objects given as params) - method calls in log statements This is the patch

Re: AWT Dev AWT impact of deprecating/changing SecurityManager#checkTopLevelWindow, checkSystemClipboardAccess, checkTopLevelWindow

On 9/2/2013 8:49 AM, Alan Bateman wrote: This is a follow-up to thread from June [1] where I proposed deprecating the SecurityManager checkTopLevelWindow, checkSystemClipboardAccess, checkTopLevelWindow methods. At the time then Anthony agreed with the spec change but I didn't come back

Re: AWT Dev 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

Alan, The change looks good. A minor one - in the class description of java.lang.SecurityManager, I suggest to remove the references to java.awt.AWTPermission line 143 and 214. Mandy On 12/10/2013 5:51 AM, Alan Bateman wrote: In JDK 8 we deprecated the JDK 1.1-era SecurityManager

Re: AWT Dev [9] Review Request: 8037485 Refactor java.awt.datatransfer to eliminate dependency on AWT

On 7/23/2014 6:53 AM, Petr Pchelko wrote: Hello, Alan. I'm skimmed over the updated webrev, it mostly looks good except for getFlavorMap where it doesn't set map, I assume you meant to do this: if (map == null) flavorMap = map = supplier.get(); Thank you! Updated the fix:

AWT Dev Review request: JDK-8073373: Remove redundant imports from sun/applet/AppletProps.java

Simple patch: --- a/src/java.desktop/share/classes/sun/applet/AppletProps.java +++ b/src/java.desktop/share/classes/sun/applet/AppletProps.java @@ -28,8 +28,6 @@ import java.awt.*; import java.io.*; import java.util.Properties; -import sun.net.www.http.HttpClient; -import

Re: AWT Dev [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module

On 1/13/15 7:45 AM, Sergey Bylokhov wrote: On 13.01.2015 17:23, Alan Bateman wrote: Typo in my mail, I meant verify-modules. They are currently issues with verify-modules and boot cycle builds so I think verify-modules is currently disabled (at least in jdk9/dev). Erik is working on this via

Re: AWT Dev [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module

On 1/13/15 9:34 AM, Sergey Bylokhov wrote: On 13.01.2015 20:26, Mandy Chung wrote: On 1/13/15 7:45 AM, Sergey Bylokhov wrote: On 13.01.2015 17:23, Alan Bateman wrote: Typo in my mail, I meant verify-modules. They are currently issues with verify-modules and boot cycle builds so I think

Re: AWT Dev [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module

On 1/13/2015 11:30 AM, Sergey Bylokhov wrote: On 13.01.2015 21:51, Alan Bateman wrote: I think this looks okay. I see Mandy's comment about dropping the dependency on sun.security.util and that would be good to do (but can be another patch if you want). ok. The new versions:

Re: AWT Dev [9] Review Request: 8039269 images/cursors should not be in ${java.home}/lib

On 2/13/15 10:01 AM, Sergey Bylokhov wrote: http://cr.openjdk.java.net/~serb/8039269/webrev.00/root http://cr.openjdk.java.net/~serb/8039269/webrev.00/jdk I looked at java/awt/Cursor.java that looks fine to me Minor comment on java/awt/Cursor.java line 166, 167: all caps are

Re: AWT Dev RfR JDK-8055160

On 3/16/2015 1:52 PM, Pete Brunet wrote: The following patch to accessibility related code is for the modularity effort. http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.00/ Toolkit: line 799-804: this can simply be replaced with Class? clazz = Class.forName(atName, false, cl);

Re: AWT Dev 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: AWT Dev RfR JDK-8055160

On 3/19/2015 6:03 PM, Pete Brunet wrote: A new webrev is available at http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.01/ line 820-821: this comment is incorrect. line 831-838: what happens if ServiceConfigurationException thrown or any exception is thrown by the activate method?

Re: AWT Dev RfR JDK-8076552 nightly build break fix

This API is only available on windows but not other platforms. I think src/windows/classes is the right location. Mandy On 4/7/2015 10:51 PM, Pete Brunet wrote: Please review/approve the following patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/ The recent push for

Re: AWT Dev RfR JDK-8055160

On 4/3/2015 1:59 PM, Pete Brunet wrote: Due to the recent push of JDK-8076182 (Open source Java Access Bridge) which exposed some files that were in closed the webrev needs a full re-review. I've also made the changes requested by Mandy.

Re: AWT Dev RfR JDK-8076552 nightly build break fix

I agree with Phil's suggestion and file a bug to follow up the javadoc build issue. You can verify the result from make docs that there is no javadoc generated for this package on windows build. Mandy On 4/8/2015 10:29 AM, Phil Race wrote: Isn't it sufficient to comment out this one line ?

Re: AWT Dev RfR JDK-8076552 nightly build break fix

+1 Mandy On 4/8/2015 11:00 AM, Phil Race wrote: That looks good to me. -phil. On 4/8/2015 10:55 AM, Pete Brunet wrote: How's this? http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03 On 4/8/15 12:47 PM, Mandy Chung wrote: I agree with Phil's suggestion and file a bug to follow up

Re: AWT Dev RfR JDK-8055160

On Jun 12, 2015, at 1:07 PM, Pete Brunet peter.bru...@oracle.com wrote: Thanks Mandy, The new patch is at http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.04 Looks good. Thanks. On 6/10/15 6:29 PM, Mandy Chung wrote: On Jun 10, 2015, at 3:33 PM, Pete Brunet peter.bru

Re: AWT Dev RfR JDK-8055160

On Jun 10, 2015, at 3:33 PM, Pete Brunet peter.bru...@oracle.com wrote: Due to some other priorities it's been over 2 months since the last webrev. An update is here: http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 BarProvider.java You can use try-with-resource try

Re: AWT Dev RfR JDK-8055160

-8076182 (Open source Java Access Bridge) which exposed some files that were in closed the webrev needs a full re-review. I've also made the changes requested by Mandy. http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/ Pete On 3/23/15 4:41 PM, Mandy Chung wrote: On 3/19

Re: AWT Dev RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc

On 2015-05-21 07:33, Pete Brunet wrote: Please review the following change for 8u: http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ I only skimmed through the change. package-info.java should have @jdk.Exported. Mandy Background: - As part of the open sourcing of the

Re: AWT Dev RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities

Looks fine. Mandy On 08/13/2015 10:29 AM, Pete Brunet wrote: One final update from Mandy: - change test path to remove jdk.accessibility; only use package name for path - add @modules java.desktop jdk.accessibility http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.03/ Pete On 7/16/15

Re: AWT Dev RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities

Moving the internal classes to com.sun.java.accessibility.internal is right as com.sun.java.accessibility is a supported API. Sean is right that no need to specify /secure=java.lang.SecurityManager. Mandy On Jul 14, 2015, at 11:57 PM, Sean Mullan sean.mul...@oracle.com wrote: You don't

Re: [9] Review Request for 8067470: Examine if the replacement for sun.awt.SunToolkit.setLWRequestStatus should be provided

On 09/25/2015 04:32 AM, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8067470 webrev: http://cr.openjdk.java.net/~ssadetsky/8067470/webrev.00/ The corresponding java.awt.Window method is proposed. The method is protected by a newly

Re: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections

cc'ing awt-dev. This change looks okay. Mandy > On Dec 11, 2015, at 9:22 AM, Chris Hegarty wrote: > > More technical debt in sun.misc… > > Java SE has had support for Queues in Collections for many major releases, > sun.misc.Queue seems to predate that. I cannot

Re: RFR [9] 8146735: Move sun.misc.PerformanceLogger to sun.util.logging

> On Jan 12, 2016, at 10:30 AM, Chris Hegarty wrote: > > Webrev updated in-place, moved to sun.awt.utli ( desktop module ) > > http://cr.openjdk.java.net/~chegar/8146735/ This looks fine. Good to see it moved to java.desktop. Mandy

Re: RFR [9] 8146735: Move sun.misc.PerformanceLogger to sun.util.logging

On Jan 10, 2016, at 1:19 AM, Chris Hegarty wrote: > > In preparation for JEP 260, and as per the suggestion over on the core > libs[1], > sun.misc.PerformanceLogger should be moved to sun.util.logging. > > http://cr.openjdk.java.net/~chegar/8146735/ Why not moving

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

The client team owns jdk.jsobject module and so I add awt-dev to this thread. And bcc jdk9-dev. It is not Java SE API and it should not add to CORE-PKGS.gmk. As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm. Mandy >

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

EAPI),$(COREAPI_DOCSDIR)/); \ > + ) >> $@ > + > +# Create a file with the package names in it > +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS)) > + $(prep-target) > + $(call PackageFilter,$(JSOBJECT_PKGS)) > + > + > +##

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

rev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01 >>http://cr.openjdk.java.net/~dtitov/8156960/webrev.01 >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960 >> >> Thank you! >> >> Best regards, >> Daniil >> >>

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

> On Jun 9, 2016, at 9:08 AM, Daniil Titov wrote: > > Thank you, Erik! > > Please review the new version of the patch that has "../" fixed: > > Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.02 >

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

his would argue that this API >> should also be deprecated in JDK 9 with forRemoval=false, and revisited at >> the same time as Applet. But I could be mistaken, and it might make sense to >> treat the plugin separately from Applet. >> >> s'marks >> >> On

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

Goo.d It should have forRemoval=true in @Deprecated then. Mandy > On Jun 8, 2016, at 1:13 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > Yes, the plan is to deprecate it in 9 and remove it in a future release. > > -- Kevin > > > Mandy Chu

Re: Review-request for 8143227: Platform-Specific Desktop Features

> On Mar 4, 2016, at 11:07 AM, Phil Race wrote: > > Approved. > > -phil. > > One comment on something you can't do anything about *yet*, is > that adding a new API package right in the same time frame jigsaw is > merging in to JDK9 creates a probable time window for a

Re: Review-request for 8143227: Platform-Specific Desktop Features

> On Mar 5, 2016, at 1:48 AM, Alexander Zvegintsev > <alexander.zvegint...@oracle.com> wrote: > > Fixed: http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/09/ modules.xml change looks fine. Thanks for the update. Mandy > > -- > Thanks, > Alexander. > >

Re: [9] Review request for 8154539 Examine the desktop module's use of sun.misc.SoftCache

> On May 11, 2016, at 2:55 PM, Alexander Scherbatiy > wrote: > > On 12/05/16 01:50, Phil Race wrote: >> Alexander ... I am concurrently deleting GThreadHelper (see webrev I just >> sent out) >> which is covered by a separate bug so please revert that part of

Re: [9] Review request for 8154539 Examine the desktop module's use of sun.misc.SoftCache

> On May 11, 2016, at 1:07 PM, Alexander Scherbatiy > wrote: > > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8154539 > webrev: http://cr.openjdk.java.net/~alexsch/8154539/webrev.00 > > This is a request from the

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

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

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: 8177672 DataFlavor.imageFlavor is null when the java.desktop module is not resolved

> On Mar 31, 2017, at 1:10 PM, Alan Bateman wrote: > > On 31/03/2017 17:36, Sergey Bylokhov wrote: > >> Hello, >> Please review the fix for jdk9. >> >> There is an optional dependency of java.datatransfer module from >> java.desktop. If the java.desktop module is not

Review Request: JDK-8174977: Update license files with consistent license/notice names

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8174977/webrev.00/index.html Small edits to the license files, contributed by jeannette.h...@oracle.com. I am sponsoring it. Also I have reviewed it. Mandy

Re: [9] Review Request: 8177672 DataFlavor.imageFlavor is null when the java.desktop module is not resolved

> On Apr 3, 2017, at 6:58 AM, Sergey Bylokhov > wrote: > >>> >>> "Return null if java.awt.Image is not visible, the java.desktop module is >>> not loaded, or the java.desktop module is not in the run-time image." >> >> This is better. >> >> Sergey - the “not

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

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

Re: Java 9 on OS X internal API com.apple.eio.FileManager

On 9/26/17 2:10 PM, Michael Hall wrote: The example below seems to be something that would be better off in java.nio.files and so would not have been appropriate for the desktop JEP and you may want to file an RFE against core-libs/java.nio I would agree this might not be the best fit to

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

This is a very good change and no more mapfile to maintain!! Please do file JBS issues for the component teams to clean up their exports. Mandy On 3/23/18 7:30 AM, Erik Joelsson wrote: I have looked at the build changes and they look good. Will you file followups for each component team to

Re: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped

On 9/16/18 12:48 AM, Alan Bateman wrote: On 15/09/2018 22:00, Philip Race wrote: It was exported  in the past .. and it was publicly documented .. http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html .. so I think Sergey was correct in his "JDK" scope.

Re: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped

On 9/13/18 2:43 PM, Sergey Bylokhov wrote: Hello. Please review fix for jdk12. Bug: https://bugs.openjdk.java.net/browse/JDK-8210692 Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00 CSR: https://bugs.openjdk.java.net/browse/JDK-8210693 Thus change looks okay to me.  This class is

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

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

and 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 (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

On 11/13/19 10:50 AM, gerard ziemski wrote: Hi all, Please review this cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself: I'm including core-libs and awt in this review because the proposed fix touches their

Re: RFR: JDK-8241463 Move build tools to respective modules

Hi Magnus, Modularizing the build tools is a good move.    This patch suggests to place the build tools under     src/$MODULE/share/tools/$PACKAGE/*.java I think the modular source location of the build tools needs more discussion, including jigsaw-dev for this discussion. The JDK source

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

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

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