Re: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from make to respective module [v2]

On Tue, 8 Dec 2020 18:16:15 GMT, Mandy Chung wrote: >> @wangweij Moving build tools is a related, but separate, question, which is >> addressed by https://bugs.openjdk.java.net/browse/JDK-8241463. >> >> I send out a review earlier this year (see >> https://m

Re: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from make to respective module [v2]

On Tue, 8 Dec 2020 16:19:05 GMT, Magnus Ihse Bursie wrote: >> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into >> java.base as well? >> >> Update: I see all subdirs in tools are still there. > > @wangweij Moving build tools is a related, but separate, question, which is >

Re: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from make to respective module [v2]

On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Move to share/data, and move jdwp.spec to java.se > > I have reviewed all lines in the patch file with or near

Re: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] RFR: 8200129 : Remove D3D Performance Counter.

+1 Mandy On 3/22/18 1:33 PM, Phil Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8200129 webrev: http://cr.openjdk.java.net/~prr/8200129/ It was noted in another thread [1] that we had a couple of qualified exports from java.base to java.desktop that are platform-specific but are

Re: [OpenJDK 2D-Dev] [9] Review Request: 8181894 java.desktop module documentation has links to technotes

> On Jun 18, 2017, at 1:33 PM, Sergey Bylokhov > wrote: > > It seems that there is an issue in generation of html files from .md. But I > have verified the new links by creating specs/jar/jar.html manually: > http://cr.openjdk.java.net/~serb/8181894/webrev.01 >

Re: [OpenJDK 2D-Dev] [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: [OpenJDK 2D-Dev] [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: [OpenJDK 2D-Dev] RFR: 8178708: Regtest failure: java/awt/Color/LoadProfileWithSM.java

> On Apr 14, 2017, at 8:47 AM, Phil Race wrote: > > Bug: http://cr.openjdk.java.net/~prr/8178708/ > Webrev : http://cr.openjdk.java.net/~prr/8178708/ > > As of the b163 module system refresh, accessing resources in a modular image > requires a new RuntimePermission. > > Since we were lacking t

Re: [OpenJDK 2D-Dev] RFR: 8051519

> On Feb 8, 2016, at 12:40 PM, Phil Race wrote: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8051519 > This internal AP being deprecated in preparation for removal in JDK 10. > Ordinarily we would remove it directly but it is known to be used by > non-JDK code, hence the deprecation. CCC a

Re: [OpenJDK 2D-Dev] RFR: 8147443: Use Common Cleaner in Marlin OffHeapArray

The change in modules.xml is fine. Mandy > On Jan 19, 2016, at 7:32 AM, Laurent Bourgès > wrote: > > Phil, > > I adopted your approach and please review the updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-Cleaner.2/ > > Changes: > - RendererContext: added cleanerObj used

Re: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on sun.nio.cs from AWT and Motif code

On 3/25/15 3:48 PM, Phil Race wrote: Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/ sun/font/XMap.java +jclass = "JIS0201"; // CHECK +jclass = "MS950_HKSCS_XP"; // CHECK What is the CHECK comment? Otherwise, looks okay. Thank you for removing java.desk

Re: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on sun.nio.cs from AWT and Motif code

On 03/16/2015 02:32 PM, Phil Race wrote: Here is an updated fix that instead of removing the sun.nio dependency instead removes the jdk.charsets static dependency. From the internal API point of view its sun.nio.cs.ext that is the issue, not sun.nio http://cr.openjdk.java.net/~prr/8035302.1/

Re: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on sun.nio.cs from AWT and Motif code

On 2/19/2015 8:57 PM, Phil Race wrote: On 2/19/15 8:50 PM, Mandy Chung wrote: On 2/19/2015 4:23 PM, Phil Race wrote: http://cr.openjdk.java.net/~prr/8035302/ I'll let Sherman and others to do the detailed review here. Minor comment: FontDescriptor.java line 56-58: can use try

Re: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on sun.nio.cs from AWT and Motif code

On 2/19/2015 4:23 PM, Phil Race wrote: http://cr.openjdk.java.net/~prr/8035302/ I'll let Sherman and others to do the detailed review here. Minor comment: FontDescriptor.java line 56-58: can use try-with-resource. line 62: should it throw UncheckedIOException? With this change, for

Re: [OpenJDK 2D-Dev] RFR: 8035301: Eliminate dependency on sun.text from font code

On 5/23/14 2:50 PM, Phil Race wrote: http://cr.openjdk.java.net/~prr/8035301/ https://bugs.openjdk.java.net/browse/JDK-8035301 Builds cleanly. Client tests run. Looks good to me.Thanks for doing another good cleanup for modularization. Mandy

Re: [OpenJDK 2D-Dev] 8038876: Remove use of ServiceLoader in locating sun.java2d.cmm.CMMServiceProvider

On 5/9/2014 3:41 PM, Phil Race wrote: http://cr.openjdk.java.net/~prr/8038876/ https://bugs.openjdk.java.net/browse/JDK-8038876 Looks good. Another one to help the job of jigsaw .. Thank you for taking care of it. Mandy

Re: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in finding class implementing sun.java2d.pipe. RenderingEngine

On 5/7/2014 2:57 PM, Phil Race wrote: I did away with the doPrivileged and it seems fine ... http://cr.openjdk.java.net/~prr/8038875.1/ I'm glad that the doPrivileged block is reduced just to System.getProperty. Looks good while I still think it's worth considering replacing Class.forName(p

Re: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in finding class implementing sun.java2d.pipe. RenderingEngine

On 5/7/2014 12:40 PM, Phil Race wrote: On 5/7/14 12:26 PM, Mandy Chung wrote: On 5/7/2014 11:26 AM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8038875 http://cr.openjdk.java.net/~prr/8038875/ Thanks for taking this on. I have some minor comments: line 129: if

Re: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in finding class implementing sun.java2d.pipe. RenderingEngine

On 5/7/2014 12:26 PM, Mandy Chung wrote: On 5/7/2014 11:26 AM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8038875 http://cr.openjdk.java.net/~prr/8038875/ Thanks for taking this on. I have some minor comments: line 129: if sun.java2d.renderer is set, it finds a custom

Re: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in finding class implementing sun.java2d.pipe. RenderingEngine

On 5/7/2014 11:26 AM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8038875 http://cr.openjdk.java.net/~prr/8038875/ Thanks for taking this on. I have some minor comments: line 129: if sun.java2d.renderer is set, it finds a custom RenderingEngine from the bootclasspath (as the

Re: [OpenJDK 2D-Dev] Custom rendering engines in jk9

On 4/2/14 12:10 AM, Laurent Bourgès wrote: For now to use marlin, I use the bootclasspath append option to load the marlin classes. Will it still work on jdk9 ? This is TBD. We recognize the dependency on the bootclasspath. > With Jigsaw in JDK 9, the access control rules will be extended to

Re: [OpenJDK 2D-Dev] Custom rendering engines in jk9

On 4/1/14 3:09 AM, Laurent Bourgès wrote: Phil, In the following bug, you propose to remove the ServiceLoader in the RenderingEngine class: https://bugs.openjdk.java.net/browse/JDK-8038875 For now the jdk has only ductus and pisces engines but I am working on marlin which is an improved pisc

Re: [OpenJDK 2D-Dev] RFR: JDK-8035821: Move psfont properties files from src/share/classes to src/share/lib

Hi Phil, Is psfont*.properties* file more of a resource file? Is there any reason (or specification) that psfont*.properties has to be in JRE/lib directory? One potential reason might be the startup performance (warm start/cold start) to avoid opening a jar file? They don't look like a user-

[OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 2 new changesets

Changeset: ec67b240b727 Author:mchung Date: 2009-09-29 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ec67b240b727 6879044: Eliminate the dependency on logging from the AWT/2D/Swing classes Summary: Replace calls to Logger with sun.util.logging.PlatformLogger Reviewed-b

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: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] 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

[OpenJDK 2D-Dev] 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

[OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6818072: Load Ductus using Class.forName if exist instead of using the service loader

Changeset: e61d93fc8ed1 Author:mchung Date: 2009-04-14 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e61d93fc8ed1 6818072: Load Ductus using Class.forName if exist instead of using the service loader Summary: First attempt Class.forName to load Ductus class before usi