Re: [OpenJDK 2D-Dev] RFR: 8272805: Avoid looking up standard charsets

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20

Re: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

On Tue, 1 Jun 2021 15:21:33 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/576161d15423f58281e384

Re: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6]

On Mon, 31 May 2021 15:02:57 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: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Fri, 21 May 2021 18:00:13 GMT, Phil Race wrote: > Are you suggesting that the patch doesn't need testing as it is ? It should > be the same either way. > It is very straight forward to run the automated tests across all platforms > these days. > I get the impression that no one is guaranteei

Re: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote: >> That is unfortunate, but nonetheless I think required to be done. >> We have acknowledeged this can't reasonably be called an RFE, so the JEP is >> introducing bugs/technical debt/call it what you will. This should generally >> be part of a

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: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 315: >> >>> 313: * >>> 314: * @since 1.0 >>> 315: * @deprecated The Security Manager is deprecated and subject to >>> removal in a >> >> Javadoc will prefix, in bold, "D

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: 8189198: Add "forRemoval = true" to Applet API deprecations

On Wed, 17 Mar 2021 16:44:19 GMT, Andy Herrick wrote: > I cannot find any instances where the scope can be narrowed Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods? - PR: https://git.openjdk.java.net/jdk/pull/2920

Re: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with BufferedInputStream [v5]

On Mon, 15 Mar 2021 12:19:19 GMT, Сергей Цыпанов wrote: >> In some cases wrapping of `InputStream` with `BufferedInputStream` is >> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which >> does not require any buffer having one within. >> >> Other cases are related to readi

Re: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with BufferedInputStream [v4]

On Sun, 14 Mar 2021 19:32:11 GMT, Сергей Цыпанов wrote: > Done I think I'd prefer if the exception message would say that the JMOD is invalid or that the JMOD file is truncated (because I don't think anyone seeing this exception will know anything about the header). - PR: https:

Re: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with BufferedInputStream [v2]

On Sun, 14 Mar 2021 17:34:12 GMT, Сергей Цыпанов wrote: >> src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 58: >> >>> 56: byte[] magic = in.readNBytes(4); >>> 57: if (magic.length != 4) { >>> 58: throw new IOException("Header expected to

Re: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with BufferedInputStream

On Sat, 13 Mar 2021 22:29:23 GMT, Сергей Цыпанов wrote: > In some cases wrapping of `InputStream` with `BufferedInputStream` is > redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does > not require any buffer having one within. > > Other cases are related to reading ei

Re: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to Applet API deprecations

On Sat, 13 Mar 2021 00:43:33 GMT, Alexander Matveev wrote: >> implementation of >> JDK-8256145: JEP 398: Deprecate the Applet API for Removal > > Marked as reviewed by almatvee (Committer). Have you looked at narrowing the use of the SuppressWarnings to local variable declarations to avoid add

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

On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to > src/java.base/share/classes/java/lang? > @AlanBateman When I moved the cha

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

On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie wrote: >> Marked as reviewed by prr (Reviewer). > > This PR is not stale; it's just still waiting for input from @AlanBateman. @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? - PR:

Re: [OpenJDK 2D-Dev] RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov wrote: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be

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

On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie wrote: >> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, >> `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good >> overall. > > I think this is almost ready to be pushed, but I'd like to have some

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

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote: >> Also, to clarify, for me there is a fundamental difference between >> `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files >> that are part of the module, owned by the content team, and the `$M

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

On Tue, 8 Dec 2020 08:32:28 GMT, Magnus Ihse Bursie wrote: >> @mlchung If you don't have any strong preference, I implore you to accept >> this change. I **vastly** prefer to move the data out of `make`! >> >> This is not just about Skara tooling. When working with make files, autoconf >> and

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

On Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie wrote: > And I can certainly move jdwp.spec to java.base instead. If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with jav

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

On Fri, 4 Dec 2020 10:29:48 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by >

Re: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]

On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > Andy Herrick has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase.

Re: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote: >> @dholmes-ora raises a good point. Hopefully there is a balance point between >> a dozen different bugs / pull requests >> each targeting one area and one bug / PR targeting a dozen separate areas. I >> don't have a good general rule to su

Re: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy wrote: >> Before this Enhancement can be formally reviewed, you will need a JBS bug >> ID. If you are already working with a >> Committer or Reviewer in the `jdk` project who has agreed to sponsor your >> change, they can file the Enhancement

Re: [OpenJDK 2D-Dev] RFR: JDK-8241463 Move build tools to respective modules

On 23/03/2020 19:03, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore. Instea

Re: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

On 18/07/2019 16:32, Brian Burkhalter wrote: Resuming this topic, what is the general view on the three possible paths: 1. Override write(byte[]) at the risk of incompatibility. 2. Instead add writeBytes(byte[]) as in ByteArrayOutputStream. 3. Resolve as Won’t Fix. For 2 or 3 the incorrect clas

Re: [OpenJDK 2D-Dev] RFR: 8200129 : Remove D3D Performance Counter.

On 22/03/2018 20:33, Phil Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8200129 webrev: http://cr.openjdk.java.net/~prr/8200129/ This looks okay to me. -Alan

[OpenJDK 2D-Dev] Fwd: [PATCH] Fix compiler warnings with newer GCC 7.2.1

This was sent to core-libs-dev, I assume it was meant for 2d-dev and serviceability-dev. Forwarded Message Subject:[PATCH] Fix compiler warnings with newer GCC 7.2.1 Date: Fri, 2 Feb 2018 16:12:08 -0800 From: Indu Bhagat To: core-libs-...@openjdk.java.net

Re: [OpenJDK 2D-Dev] RFR: 8178708: Regtest failure: java/awt/Color/LoadProfileWithSM.java

On 14/04/2017 16:47, 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 that permission getResour

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8129822: Define "headful" jtreg keyword

On 25/06/2015 00:42, joe darcy wrote: : diff -r db09207cc779 test/TEST.ROOT --- a/test/TEST.ROOTWed Jun 24 15:15:10 2015 -0700 +++ b/test/TEST.ROOTWed Jun 24 16:33:09 2015 -0700 @@ -8,8 +8,11 @@ # would not count as "randomness" by this definition.) Extra care # should be taken to ha

Re: [OpenJDK 2D-Dev] RFR: JDK-8076468 Add @modules to tests in jdk_desktop test group

On 22/06/2015 16:44, Alexander Kulyakhtin wrote: Hi, Could you, please, review the test-only changes for the JDK-8076468 CR: JDK-8076468 "Add @modules to the tests in jdk_desktop test group" Webrev: http://cr.openjdk.java.net/~akulyakh/8076468/webrev.05/ @modules keywords have been added to th

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

On 28/05/2015 10:10, Volker Simonis wrote: : Yes, but as I wrote, there is a hard dependency from some of the sun.font classes to some non-standard charsets: sun.font.X11GB2312 -> sun.nio.cs.EUC_CN sun.font.X11GBK -> sun.nio.cs.GBK sun.font.X11KSC5601 -> sun.nio.cs.EUC_KR If I decide that I don

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

On 27/05/2015 18:14, Phil Race wrote: Hi Volker, Sorry for breaking AIX but I think it may be more related to these bugs https://bugs.openjdk.java.net/browse/JDK-8073152 https://bugs.openjdk.java.net/browse/JDK-8073893 8035302 then takes advantage of these but did not create/update the per-plat

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

On 31/03/2015 22:16, Phil Race wrote: Its a fixed set, but what I have here is using a public means to grab the same information previously obtained from the same internal source by internal means. I do not see it as worth my time to create and test and maintain a map when this should work fine a

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

On 26/03/2015 16:28, Xueming Shen wrote: An alternative is to simply grip the names and build a small internal mapping for those used by the fonts, it's a limited/small/fixed list, I assume. That might be look better than the current hacky one. So a small name -> historical name map? If that

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

On 25/03/2015 22:48, Phil Race wrote: Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/ - removed the jdk.charsets export to java.desktop from modules.xml - removed the COMPOUND_TEXT support which likely has not been used since Motif support was removed This looks good to me. The code

Re: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API references to java.awt.peer

On 05/03/2015 12:51, Sergey Bylokhov wrote: The new version of the fix: http://cr.openjdk.java.net/~serb/8074028/webrev.06 Font.getPeer() was renamed to Font.getFontPeer(). This part looks good to me. I assume someone working in this area will give the rest of the changes a thorough review. -

Re: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

On 04/03/2015 15:03, Magnus Ihse Bursie wrote: I believe all warnings are important to check! Unfortunately, this has not been done for a lot of warnings for a lot of time. :( Right, although in the past we had some areas close to be cleared of warnings, it's just that we didn't keep up the effo

Re: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API references to java.awt.peer

On 04/03/2015 12:37, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 9. There are a number of public API whichreference the unsupported java.awt.peer interfaces. public java.awt.Component.getPeer() @deprecated 1.1 public java.awt.Font.getPeer() @deprecated 1.1 public java.awt.MenuC

Re: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

On 04/03/2015 13:17, Magnus Ihse Bursie wrote: : I intend to file individual bugs to handle these remaining warnings, so the net result will be a completely warning free build. I also intend to file individual bugs on all the libraries that has had warnings disabled. I expect the outcome of

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

On 20/02/2015 22:30, Phil Race wrote: On 2/20/2015 1:48 PM, Alan Bateman wrote: : 1. For the record, can you explain why the X11 charsets can't move to jdk.charsets? I have a vague recollection that they aren't standard but I can't recall any details. They aren't stand

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

Mandy pointed to me to this review thread, I'm not otherwise on 2d-dev. First, just to put more context on this. The API for charsets is java.nio.charsets. It has a service provider interface and the module jdk.charsets is intended to be a service provider module with the double byte / exten

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress windows-specific deprecation warnings in the java.desktop module

On 16/12/2014 18:29, Phil Race wrote: Yes .. no technical constraint there. Although I was pondering going further and seeing if we can actually remove the public method java.awt.peer.Peer Component.getPeer() since with the module system the peer package is not accessible and this is then even

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress windows-specific deprecation warnings in the java.desktop module

On 16/12/2014 06:07, joe darcy wrote: Hello, Please review the next step of suppressing the deprecation warnings the client libraries, this time in windows-specific desktop code: JDK-8067092: Suppress windows-specific deprecation warnings in the java.desktop module http://cr.openjdk

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module

On 12/12/2014 20:46, Phil Race wrote: : 2) Some significant fraction of all the warnings are for getPeer() :- dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: warning: [deprecation] getPeer() in Component has been deprecated The issue here is that the deprecation javadoc ta

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module

On 10/12/2014 00:41, joe darcy wrote: Hello, In support of JEP 212: Resolve Lint and Doclint Warnings (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please review the large but straightforward set of changes in the webrev: http://cr.openjdk.java.net/~darcy/8066621.0/ So

Re: [OpenJDK 2D-Dev] RFR: 8056216 : Remove "sun" directory layer from libawt and common

On 19/09/2014 17:22, Phil Race wrote: Gosh that's going to be a pain to maintain .. here's an update to the 334 affected lines in that file ! Look ok ? http://cr.openjdk.java.net/~prr/8056216.1 -phil Ideally there should be just one line per directory, it should only list individual files for

Re: [OpenJDK 2D-Dev] RFR [9] Modular Source Code

On 28/08/2014 20:36, Phil Race wrote: * All of the awt-related directories (libawt_* and common) include an unnecessary extra layer, the "sun" directory. It is not needed anymore, Let's *not* do that. It also affects the destination package. Remember sun.* is the protected top-level package ..

Re: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

On 19/05/2014 07:53, Paul Sandoz wrote: If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue. If you do decide to split this then it will require crea

Re: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

On 14/05/2014 09:15, Paul Sandoz wrote: : And here what could have been a 2 line change is 25 .. http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/sun/font/StandardTextSource.java.sdiff.html So I would say leave the variable names alone unle

Re: [OpenJDK 2D-Dev] RFR [8009637]: Some error messages are missing a space

On 14/04/2014 12:36, Ivan Gerasimov wrote: Hello! It was reported that the error message in an exception is missing a space. Grep found a couple of other places with the same misformatting. Can I please have a review of the trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-800963

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

Phil, Just on Project Jigsaw and moving to a modular JDK then we've been doing preparatory work for this for several years (it had its own JEP in JDK 8 for example). There isn't a JEP yet proposing a Modular JDK but hopefully soon. In the mean-time I think we have to continue the clean-up and

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8034050: Fix serial lint warnings in javax.print

On 10/02/2014 05:12, Joe Darcy wrote: Hello, Please review the proposed fix for JDK-8034050: Fix serial lint warnings in javax.print http://cr.openjdk.java.net/~darcy/8034050.0/ I checked that the added serialVerionUID values match the serialver computations for those types on JDK 6 a

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font

On 06/02/2014 19:01, Phil Race wrote: Joe, We will get an integration going soon, so you won't have to wait too long. Its more important to be consistent in that we get the client code in the client forest. We already had to deal with a merge problem due to changes to client code made in dev.

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font

On 05/02/2014 23:55, Phil Race wrote: Joe, This help is very much appreciated but can you please re-generate your webrev against jdk9/client and I'll review it then. If this is a problem for you then instead I can take your final patch and commit into the client forest on your behalf. Let me kno

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font

On 06/02/2014 07:44, Joe Darcy wrote: For the range of @SuppressWarnings("unchecked"), if there was already a declaration handy, I put the annotation on the declaration (minimal scope). If there wasn't a declaration handy and the method was short, say less than 10 lines, I put the annotation

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font

On 05/02/2014 07:41, Joe Darcy wrote: Hello, Please review this change which resolves ~200 raw and unchecked warnings in sun.font. (Afterward, the code is also free the of the "cast" warning.) JDK-8033624 : Fix raw and unchecked lint warnings in sun.font http://cr.openjdk.java.net/~d

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033616 : Fix serial lint warnings in javax.imageio.*

On 05/02/2014 00:30, Joe Darcy wrote: Hello, Please review this simple patch to add serialVersionUID fields to several serializable types in javax.imageio. JDK-8033616 : Fix serial lint warnings in javax.imageio.* http://cr.openjdk.java.net/~darcy/8033616.0/ I've verified the serial

Re: [OpenJDK 2D-Dev] Should changes to client libraries be pushed to jdk9/dev instead of jdk9/client

On 31/01/2014 23:46, Joseph Darcy wrote: : Discussions are on going as to which forest client libraries fixes should go into, the client forest (where closed-source deployment changes happen to be going) or to the dev forest where all the other libraries work is going; FWIW, I favor the latte

Re: [OpenJDK 2D-Dev] Should changes to client libraries be pushed to jdk9/dev instead of jdk9/client

On 31/01/2014 09:08, Sergey Bylokhov wrote: On 26.01.2014 13:30, Alan Bateman wrote: As a side point, client changes have been going into jdk9/client rather than jdk9/dev so I just wonder if there might be changes backed up in jdk9/client that might cause issues when merged. It will be really

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8032733: Fix cast lint warnings in client libraries

On 27/01/2014 19:52, Joe Darcy wrote: : Alan, I strongly prefer to limit this patch to just cast cleanup. I understand, I was just pointing it out that some of these could use for-each and that would also eliminate the cast. : Based on the results of an exploratory jprt job, listed below

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8032733: Fix cast lint warnings in client libraries

On 26/01/2014 09:30, Alan Bateman wrote: The only non-client changes that I see are to Setup.gmk (previously reviewed on build-dev) and Sdp.java. I see the others now, just hard to spot in a large mind-numbing patch :-) All looks good but as I look at this again then I see a few Iterator

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8032733: Fix cast lint warnings in client libraries

On 25/01/2014 19:10, Joe Darcy wrote: Hello, Please review my large, but largely straightforward, changes to fix JDK-8032733: Fix cast lint warnings in client libraries http://cr.openjdk.java.net/~darcy/8032733.0/ Many of the changes were enabled by the clone method of an array being

Re: [OpenJDK 2D-Dev] RFR(S): JDK-8031134 : PPC64: implement printing on AIX

On 02/01/2014 17:22, Volker Simonis wrote: Hi, could somebody please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8031134/ It's the straight forward implementation of the basic printing infrastructure on AIX and shouldn't have any impact on the existing platfo

Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

On 26/11/2013 16:23, Volker Simonis wrote: Hi, thanks to everybody for the prompt and helpful reviews. Here comes the final webrev which incorporates all the corrections and suggestions from the second review round: http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ I've successfully buil

Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

On 21/11/2013 15:54, Volker Simonis wrote: : But actually I've just realized that it is not need at all, because 'aix_close.c' isn't in the PATH for any other OS than AIX (that could be probably called a feature of the new file layout:) So I'll simply change it to: 48 ifeq ($(OPENJDK_TARGE

Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

On 20/11/2013 18:26, Volker Simonis wrote: Hi, this is the second review round for "8024854: Basic changes and files to build the class library on AIX ". The previous reviews can be found at the end of this mail in the references section. I'

Re: [OpenJDK 2D-Dev] 8017109: Cleanup overrides warning in src/solaris/classes/sun/print/AttributeClass.java

On 21/06/2013 09:45, Chris Hegarty wrote: : Alternatively, someone from the "2d" area could sponsor Kurchi's changeset into 2d. Kurchi is a jdk8 committer so she should be able to push to any of the jdk8 integration forests, including jdk8/2d if that is where this has to go. -Alan

Re: [OpenJDK 2D-Dev] Add optional support for using the system libicu

On 05/06/2013 19:02, Phil Race wrote: Yes, please support the old build system. Is this really necessary? The old build is a tax and we really need it to die. In this case, it's a new feature and I don't see any point in anyone spending time adding this support to the old build. -Alan

Re: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native

On 01/04/2013 23:16, Dan Xu wrote: Hi All, In this fix, I have updated files in JDK libraries to use @Native annotation instead of @GenerateNativeHeader to mark classes that contain no native methods but constants used by native codes. @GenerateNativeHeader was added earlier in the developm

Re: [OpenJDK 2D-Dev] [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u

Konstantin, Can you hold off pushing these tests until there has been wider review? I may be mistaken but I think that many of these tests (at least for the non-client areas) were deliberately not pushed to jdk7u and jdk8 when bringing the port in. From what I can remember there was overlap wi

Re: [OpenJDK 2D-Dev] Warning Fixes from LJC Hack Session

On 04/02/2012 07:48, Michael Barker wrote: I see Rémi has suggested a slice& dice but I think that's a bit too much work for the changes involved. Instead I would suggest a simple split, send the AWT/Printing/Beans changes to awt-dev + 2d-dev, and everything else to core-libs-dev. Attached is a

Re: [OpenJDK 2D-Dev] Code Review 7110002: Rename xawt/libmawt.so and headless/libmawt.so so they can be colocated with libawt

On 09/11/2011 12:28, Chris Hegarty wrote: Hi, CR 7110002 proposes to rename the unix version of the awt toolkit libraries to allow them reside in the same directory as libawt. xawt/libmawt.so -> libawt_xawt.so headless/libmawt.so -> libawt_headless.so The proposed new library names ar

Re: [OpenJDK 2D-Dev] code review request: 7087428: move client tests out of jdk_misc

Weijun Wang wrote: Updated: root: http://cr.openjdk.java.net/~weijun/7087428/control/webrev.00/ jdk: http://cr.openjdk.java.net/~weijun/7087428/webrev.01/ I also update Makefile to put jdk_sound to its correct alphabetical position. The changes look okay to me. The jdk_misc batch is still an o

Re: [OpenJDK 2D-Dev] code review for 7067811: Update demo/sample code to state it should not be used for production

Nils Loodin wrote: : Finally on the documentation of applications, such as the lightweight HTTP server, that are shipped for testing/debugging, the following disclaimer should be added: Applications such as the lightweight HTTP server are shipped with the JDK to help developers deploy and t

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

Anthony Petrov wrote: Hi Mandy, 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 regular client application that d

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

Anthony Petrov wrote: : I have to say that that is not the best possible solution. For instance, the sun.awt.X11 classes have many different loggers: for focus-related code, for insets-related code, and so on. If a developer debugs a particular kind of problem, (s)he doesn't need to look thro

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

Mandy Chung wrote: Here are the new webrevs: core-libs changes that include java.util.Currency: http://cr.openjdk.java.net/~mchung/6882376/webrev.00/ - Added a new jtreg test - Cleaned up PlatformLogger.java per Alan's feedback. This looks much better. A couple of additional comments:

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

Oleg Sukhodolsky wrote: On Tue, Sep 15, 2009 at 11:13 PM, Mandy Chung wrote: : complicate porting JRE implementation. How does it complicate the porting? I'm not sure that IBM's or some other's version of JDK is allowed to contain such classes, thus it may be harder to port o

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

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/ The approach seems reasonable to me. It is a bit strange to redirect the platform logging to j.u.logging if something up the stack