RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
The code change refactors classes that have a `SuppressWarnings("removal")`
annotation that covers more than 50KB of code. The big annotation is often
quite faraway from the actual deprecated API usage it is suppressing, and with
the annotation covering too big a portion it's easy to call other deprecated
methods without being noticed.
-
Depends on: https://git.openjdk.java.net/jdk/pull/4073
Commit messages:
- 8267521: Post JEP 411 refactoring: maximum covering > 50K
Changes: https://git.openjdk.java.net/jdk/pull/4138/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8267521
Stats: 226 lines in 18 files changed: 142 ins; 29 del; 55 mod
Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138
PR: https://git.openjdk.java.net/jdk/pull/4138
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]
On Wed, 19 May 2021 13:47:53 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/576161d15423f58281e384174d28c9f9be7941a1 >> The essential change for this JEP, including the `@Deprecate` annotations >> and spec change. It also update the default value of the >> `java.security.manager` system property to "disallow", and necessary test >> change following this update. >> 2. >> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 >> Manual changes to several files so that the next commit can be generated >> programatically. >> 3. >> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 >> Automatic changes to other source files to avoid javac warnings on >> deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is >> generated programmatically, see the comment below for more details. If you >> are only interested in a portion of the 3rd commit and would like to review >> it as a separate file, please comment here and I'll generate an individual >> webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for >> any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system >> property is now "disallow", most of the tests calling >> `System.setSecurityManager()` need to launched with >> `-Djava.security.manager=allow`. This is covered in a different PR at >> https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, >> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are >> reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine. I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected. - Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/4073
Accessing 'system' header fields implicitly added by HttpClient
Hi! I've recently released an HTTP cache (https://mizosoft.github.io/methanol/caching) that operates as part of an interceptor chain built atop a standard HttpClient. Currently, the cache can store only one response per request. However, request headers can specify multiple response variants if nominated by the 'Vary' header (e.g. gzip & deflate variants if varying on Accept-Encoding). To ensure a response is selected only if it is the corrected variant, incoming requests' Vary-nominated fields must match against those in the initiating request. The bummer is that HttpClient can augment requests with implicit header fields (e.g. Cookie, Authorization, etc.), and accessing these seems to be impossible (tested that with 'response.request().headers()', please correct me if I'm wrong). The cache has to render a response uncacheable if it decides it varies on these fields, as their values cannot be known in the initiating request, so they can't be matched against when new requests are made. It'd be nice if one could access these headers, maybe via 'response.request().headers()', or something like 'response.networkRequest().headers()'. This would increase cache's efficiency. Additionally, I can find it useful for debugging as it's always good to know what modifications the client makes to requests. Regards, Moataz
Integrated: 8261880: Change nested classes in java.base to static nested classes where possible
On Tue, 16 Feb 2021 14:30:58 GMT, Сергей Цыпанов wrote: > Non-static classes hold a link to their parent classes, which in many cases > can be avoided. This pull request has now been integrated. Changeset: 9425d3de Author:Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/9425d3de83fe8f4caddef03ffa3f4dd4de58f236 Stats: 15 lines in 11 files changed: 0 ins; 0 del; 15 mod 8261880: Change nested classes in java.base to static nested classes where possible Reviewed-by: redestad - PR: https://git.openjdk.java.net/jdk/pull/2589
Re: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2]
On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов wrote: >> Non-static classes hold a link to their parent classes, which in many cases >> can be avoided. > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8261880: Remove static from declarations of Holder nested classes Just for information there is similar issues in `javax.imageio.metadata.IIOMetadataFormatImpl` class in the `java.desktop` module. - PR: https://git.openjdk.java.net/jdk/pull/2589
Re: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2]
On Thu, 20 May 2021 10:42:49 GMT, Claes Redestad wrote: >> Сергей Цыпанов has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8261880: Remove static from declarations of Holder nested classes > > Marked as reviewed by redestad (Reviewer). @cl4es now you can sponsor :) - PR: https://git.openjdk.java.net/jdk/pull/2589
Re: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2]
On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов wrote: >> Non-static classes hold a link to their parent classes, which in many cases >> can be avoided. > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8261880: Remove static from declarations of Holder nested classes Marked as reviewed by redestad (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2589
Integrated: 8267262: com/sun/net/httpserver/Filter improve API documentation of static methods
On Tue, 18 May 2021 09:34:25 GMT, Julia Boes wrote: > The filter operation `Consumer` that is passed to the factory methods can > throw an unchecked exception. This change adds a note on the exception > handling in that case. It also adds a clarification to `Filter::afterHandler` > on the relation of the filter operation and the client receiving the response. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8267379 This pull request has now been integrated. Changeset: 31320c34 Author:Julia Boes URL: https://git.openjdk.java.net/jdk/commit/31320c3474a6054a367e764c2a9fef46ac638998 Stats: 50 lines in 2 files changed: 45 ins; 1 del; 4 mod 8267262: com/sun/net/httpserver/Filter improve API documentation of static methods Reviewed-by: dfuchs, chegar - PR: https://git.openjdk.java.net/jdk/pull/4085
Re: 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 sandbox for the JEP and fixed before integration of the JEP. >> From my point of view it is a blocker. > > The JEP isn't PTT for 17 so there's plenty of time isn't there ? There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover. - PR: https://git.openjdk.java.net/jdk/pull/4073
