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

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

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

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

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 are

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] 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] 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 https://bugs.openjdk.java.net/browse/JDK-8024854. The previous reviews can be found at the end of this mail in the references section. I've

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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 the

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

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't

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

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

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

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

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.

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

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

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

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

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

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 charset

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

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

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,

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

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

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

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

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

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

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

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

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:

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