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

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 as

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

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 n

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: java-atk-wrapper accessibility and openjdk9

Hi Fridrich, The maintainer of java-atk-wrapper was informed of the new javax.accessibility.AccessibilityProvider service interface during JDK 9 development.   java-atk-wrapper will need to implement a provider of AccessibilityProvider to run on JDK 9 [1]. Adding to Phil's comment, java-atk-

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 AWT

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: 9 RfR: JDK-818182: Broken link in javadoc for JSObject.getWindow

awt-dev would be a more appropriate mailing list to review this docs change. As Lance suggests, you can use ${docRoot} instead since all modules in the docs bundle have the same docRoot. You can fix it before your push. No need to see the new patch. Mandy > On Jun 15, 2017, at 10:16 AM, Lanc

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 readable” part is no longer appl

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 present then the applicat

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: 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: 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: 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: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

the same. This 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 &

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

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

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 >http://cr.openjdk.java.net/~dtitov/8156960/webrev.02/ > Looks okay. Nit:

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

API),$(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

Goo.d It should have forRemoval=true in @Deprecated then. Mandy > On Jun 8, 2016, at 1:13 PM, Kevin Rushforth > wrote: > > Yes, the plan is to deprecate it in 9 and remove it in a future release. > > -- Kevin > > > Mandy Chung wrote: >> The client team owns

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

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 the fix. > > Sorry. Here is the u

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 jigsaw team to get rid of the depe

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

> On Mar 5, 2016, at 1:48 AM, Alexander Zvegintsev > wrote: > > Fixed: http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/09/ modules.xml change looks fine. Thanks for the update. Mandy > > -- > Thanks, > Alexander. > > On 03/05/2016 04:10 AM, Mandy Chung wr

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 non-obvious conflict. >

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 it to java.desktop, perhaps

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 find any usages outside of the

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

Alexander, Since there are existing applications using com.apple.eawt and com.apple.eio internal APIs, I propose to deprecate them in JDK 9 and remove these two packages in JDK 10 to give time to existing applications to migrate to this new API. Mandy > On Nov 24, 2015, at 7:02 AM, Alexander

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 in

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

Re: 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 wrote: > > You don't need to add the /secur

Re: RfR JDK-8055160

> On Jun 12, 2015, at 1:07 PM, Pete Brunet 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

Re: RfR JDK-8055160

o me. Mandy > > Pete > > On 6/10/15 6:08 PM, Mandy Chung wrote: >> Just a quick check, jdk.accessibility is only linked in windows image at the >> moment. It is a bug. Are you going to fix that in this changeset? I think >> you have to verify this chang

Re: RfR JDK-8055160

> On Jun 10, 2015, at 3:33 PM, Pete Brunet 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 (PrintWriter writer = n

Re: RfR JDK-8055160

: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. >> >> http://cr.openjdk.java.

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

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

Re: 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: 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 JDK-807

Re: 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. http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev

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

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 sun.net.ftp.FtpClient

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

Re: [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: http://cr.openjdk

Re: [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: [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: [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: http://cr.open

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

Re: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess

Adding awt-dev for the review. Mandy On 11/12/2013 11:29 AM, Mandy Chung wrote: This is a simple code deletion in sun.misc.JavaAWTAccess and its implementation class: Webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/ This patch removes the methods from

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

Re: RFR 623 build warnings [deprecation] isLoggable(int) in PlatformLogger

Chris, Thanks for the patch. It looks fine to me. I saw that you have pushed this changeset which is fine. As for the background, we leave these deprecated methods and fields in sun.util.logging.PlatformLogger just temporarily to allow JavaFX to migrate and use the PlatformLogger.Level en

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

Re: 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: PlatformLogger: isLoggable performance / waste due to HashMap 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: Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction

. Mandy Thanks, Artem On 4/26/2012 10:49 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. Hi

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

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

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

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:

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 Revi

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

There is no change to the log messages emitted from awt/2d/swing. The only impact to the end users is if they enable logging by modifying the system-wide logging.properties (see below); otherwise, the end users will not notice any change due to this fix. The following are the common ways to e

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

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

ill never initialize or/and load Logger (et al) classes so we achieved the goal. Thanks, Andrei Oleg Sukhodolsky wrote: HI Mandy, On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung wrote: Hi Oleg, A better question to ask is who and how the logging information AWT is used for. The AWT team

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

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

Oleg, Anthony, You all raise good questions and we shall focus on the problem we want to fix by 6879044 and 6882376. It's important to separate the discussion for this fix vs the startup performance improvement. I hope below clears up some confusion and this review request is for addressin

Re: Review Request for 6879044

n the one listed above are not changed since the last version. Thanks Mandy Mandy Chung wrote: 6879044: Eliminate the dependency of logging from the JRE core/awt/swing classes Webrev: http://cr.openjdk.java.net/~mchung/6879044/webrev.00/ Summary: 1. A new sun.util.logging.PlatformLogger

Re: Review Request for 6879044

x for 6879044. I'll generate two new webrevs to separate the core-libs and awt/2d/swing stuff for the review. Thanks Mandy Alan Bateman wrote: Mandy Chung wrote: 6879044: Eliminate the dependency of logging from the JRE core/awt/swing classes Webrev: http://cr.openjdk.java.net/~mchu

Re: 6854954: Eliminate static dependency on java.awt.AWTPermission

Alan, Looks good. Minor nit in SecurityConstants.java line 148 - good to add a blank line to separate the two fields Mandy Alan Bateman wrote: Sean, Mandy - can you review this? I also need someone from the AWT team. This patch eliminates the static dependency on java.awt.AWTPermission fro

Re: Review Request for 6879044

Oleg Sukhodolsky wrote: On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung wrote: I thought that it is possible to log int a file using default logger, Not the default logging configuration. thus I was surprised that description of PlatformLogger says about System.err. I'd e

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

early? AWT team, can you confirm? > At the very least consider using the lazy holder idiom over volatile. Good point. Mandy Andrew John Hughes wrote: 2009/9/14 Mandy Chung : I'm curious as to why some of the initialisations are lazy and some are eager. Notably AWTEvent is changed fro

Re: Review Request for 6879044

Oleg Sukhodolsky wrote: On Mon, Sep 14, 2009 at 5:32 AM, Mandy Chung wrote: 6879044: Eliminate the dependency of logging from the JRE core/awt/swing classes Webrev: http://cr.openjdk.java.net/~mchung/6879044/webrev.00/ Summary: 1. A new sun.util.logging.PlatformLogger class that will handle

Review Request for 6879044

6879044: Eliminate the dependency of logging from the JRE core/awt/swing classes Webrev: http://cr.openjdk.java.net/~mchung/6879044/webrev.00/ Summary: 1. A new sun.util.logging.PlatformLogger class that will handle the log messages in a similar way as Logger but it will only delegate to jav