From duke at openjdk.org Tue Jan 2 14:13:52 2024 From: duke at openjdk.org (Yakov Shafranovich) Date: Tue, 2 Jan 2024 14:13:52 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2] In-Reply-To: References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: <7N-RSj57bmy750gwGeCCjg5cU-vF4i8iDa_MsbD4YjU=.52e762e2-3f40-4f87-8f04-9ac18194e0a0@github.com> On Fri, 10 Nov 2023 15:44:19 GMT, Yakov Shafranovich wrote: >> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: >> - Cache of JAR files in JarURLConnection class >> - Cache of JAR/ZIP files in JarFile and ZipFile classes >> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider >> - Directories and filenames with the same name considered to be the same in ZipFile class >> - Possible issues when local and central headers conflict in ZipInputStream class >> >> Related JBS report: >> https://bugs.openjdk.org/browse/JDK-8319122 > > Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision: > > - Fixed more line breaks > - fixed line breaks Still working on this ------------- PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1874073990 From mbaesken at openjdk.org Wed Jan 3 11:47:54 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 11:47:54 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" Message-ID: In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. ------------- Commit messages: - JDK-8322782 Changes: https://git.openjdk.org/jdk/pull/17241/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322782 Stats: 19 lines in 8 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/17241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17241/head:pull/17241 PR: https://git.openjdk.org/jdk/pull/17241 From alanb at openjdk.org Wed Jan 3 13:32:38 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Jan 2024 13:32:38 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" In-Reply-To: References: Message-ID: <9oRf6_NeT3KKnkiZNAwUlcK6kBs13ahenPR1iWFfcb8=.ed953023-01bb-45d0-858e-daf5d4d52093@github.com> On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken wrote: > In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. Looks fine, surprised to see so many. I assume you'll bump the copyright date on all the files before integrating. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802064657 From mbaesken at openjdk.org Wed Jan 3 13:51:03 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 13:51:03 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v2] In-Reply-To: References: Message-ID: <7MyzckmpbHdkVKO-GM7_sEkpOtRCN7wf2dBe50P7ptE=.8764e79c-d68b-4737-a906-31dadf47c140@github.com> > In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust copyright date ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17241/files - new: https://git.openjdk.org/jdk/pull/17241/files/af1c0375..c06f35b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=00-01 Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17241/head:pull/17241 PR: https://git.openjdk.org/jdk/pull/17241 From mbaesken at openjdk.org Wed Jan 3 13:55:22 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 13:55:22 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v3] In-Reply-To: References: Message-ID: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> > In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Invokers.java too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17241/files - new: https://git.openjdk.org/jdk/pull/17241/files/c06f35b5..eac9ca69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17241/head:pull/17241 PR: https://git.openjdk.org/jdk/pull/17241 From mbaesken at openjdk.org Wed Jan 3 14:04:48 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 14:04:48 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v3] In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> References: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> Message-ID: On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken wrote: >> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Invokers.java too Hi Alan, thanks for the review ! I adjust the copyright year info and also some more places in Invokers.java . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1875416193 From aivanov at openjdk.org Wed Jan 3 16:53:47 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 3 Jan 2024 16:53:47 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v3] In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> References: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> Message-ID: On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken wrote: >> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Invokers.java too Looks good to me. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802684965 From mbaesken at openjdk.org Thu Jan 4 08:09:32 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 4 Jan 2024 08:09:32 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v3] In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> References: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> Message-ID: On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken wrote: >> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Invokers.java too Hi Alexey, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1876673066 From mbaesken at openjdk.org Thu Jan 4 08:09:34 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 4 Jan 2024 08:09:34 GMT Subject: Integrated: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" In-Reply-To: References: Message-ID: <3omokFt2Z2o6tspIqc14e1qKWtD9FygYKsoXsHjHnI0=.f649ef22-6972-4008-8df0-f5e0dec1038a@github.com> On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken wrote: > In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. This pull request has now been integrated. Changeset: 1369c545 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/1369c545ac51d7b5ff623d486e28c939869fecb8 Stats: 29 lines in 9 files changed: 0 ins; 0 del; 29 mod 8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" Reviewed-by: alanb, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17241 From autumcap at amazon.com Thu Jan 4 21:03:18 2024 From: autumcap at amazon.com (Capasso, Autumn) Date: Thu, 4 Jan 2024 21:03:18 +0000 Subject: JVM security properties warning Message-ID: <8A9F9D16-7953-4A25-91FF-A7A5E72FBCD9@Amazon.com> We began investigating this issues when we noticed many developers had misconfigured security properties. One example is a search on github for Dnetworkaddress.cache.ttl: https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code this search illustrates the how developers mistake security settings for system properties and end up with misconfigurations. We see developers are misconfiguring networkaddress.cache.ttl and networkaddress.cache.negative.ttl settings, Often in the effort to increase the TTL for entries in the DNS cache, they mistakenly change the networkaddress.cache.ttl on the command line which does nothing. This means teams don?t actually end up raising the DNS cache TTL. Inadvertently leaving the cache TTL too low places more pressure on DNS servers. We would be open to at first narrowing the scope from all security properties to just the DNS cache properties and doing a proof of concept. We?ve also gotten the suggestion of implementing it by adding system property overrides for those DNS security properties. Thank you in advance, Autumn Capasso -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski1 at gmail.com Fri Jan 5 14:32:41 2024 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Fri, 5 Jan 2024 15:32:41 +0100 Subject: JVM security properties warning In-Reply-To: <8A9F9D16-7953-4A25-91FF-A7A5E72FBCD9@Amazon.com> References: <8A9F9D16-7953-4A25-91FF-A7A5E72FBCD9@Amazon.com> Message-ID: Hi Autumn, Thanks for bringing it up here. The documentation could definitely use some improvement; we could make the property documentation link to the Security class, which in turn documents the use of the java.security file. We should also remove these security properties from the system properties list (https://docs.oracle.com/en/java/javase/21/docs/api/system-properties.html). I'm not sure about exposing the DNS configuration as system properties. The configuration can already be set using undocumented system properties, but only if the corresponding security property is not set (so, for example, sun.net.inetaddr.ttl will work, but sun.net.inetaddr.negative.ttl will not). There's probably a reason why these properties are not documented, others could explain. As I'm sure you found out already, the default TTL is 30 seconds for successful lookups, 10 seconds for failed lookups. What kind of values would you use to reduce the DNS pressure? If you're looking to reduce the DNS activity, there are many other options to choose from: - use a local caching DNS resolver like systemd-resolved - cache the resolved InetAddress instance on the application level - use a custom address resolution service provider (requires JDK 18+, see https://openjdk.org/jeps/418) - use the hosts file - use a local caching DNS server The default JDK resolver uses the standard C APIs to resolve DNS hostnames, and has no access to the TTL information returned by the server. Further, negative caching does not differentiate between a negative response and a DNS failure. For that reason you should prefer using caches that have access to that information. Let me know if that helps. Regards, Daniel czw., 4 sty 2024 o 22:45 Capasso, Autumn napisa?(a): > > We began investigating this issues when we noticed many developers had misconfigured security properties. One example is a search on github for Dnetworkaddress.cache.ttl: https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code this search illustrates the how developers mistake security settings for system properties and end up with misconfigurations. We see developers are misconfiguring networkaddress.cache.ttl and networkaddress.cache.negative.ttl settings, Often in the effort to increase the TTL for entries in the DNS cache, they mistakenly change the networkaddress.cache.ttl on the command line which does nothing. This means teams don?t actually end up raising the DNS cache TTL. Inadvertently leaving the cache TTL too low places more pressure on DNS servers. We would be open to at first narrowing the scope from all security properties to just the DNS cache properties and doing a proof of concept. We?ve also gotten the suggestion of implementing it by adding system property overrides for those DNS security properties. > > > > Thank you in advance, > > Autumn Capasso > > > > From duke at openjdk.org Tue Jan 9 21:12:48 2024 From: duke at openjdk.org (Yakov Shafranovich) Date: Tue, 9 Jan 2024 21:12:48 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v3] In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: <2xlUrhw42cy8_UcZNgKYy5WMm0kupZaztNScq8TJe9w=.4c7421f7-f6be-471b-8cb9-5ced9023de65@github.com> > The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: > - Cache of JAR files in JarURLConnection class > - Cache of JAR/ZIP files in JarFile and ZipFile classes > - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider > - Directories and filenames with the same name considered to be the same in ZipFile class > - Possible issues when local and central headers conflict in ZipInputStream class > > Related JBS report: > https://bugs.openjdk.org/browse/JDK-8319122 Yakov Shafranovich 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. The pull request contains five additional commits since the last revision: - reverted zipfs changes and made adjustements for ZipInputStream comments - Merge branch 'master' into zip-doc-changes - Fixed more line breaks - fixed line breaks - document patch for JDK-8319122 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16424/files - new: https://git.openjdk.org/jdk/pull/16424/files/919666a0..dbecd485 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16424&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16424&range=01-02 Stats: 831197 lines in 4897 files changed: 202043 ins; 545027 del; 84127 mod Patch: https://git.openjdk.org/jdk/pull/16424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16424/head:pull/16424 PR: https://git.openjdk.org/jdk/pull/16424 From duke at openjdk.org Tue Jan 9 21:12:50 2024 From: duke at openjdk.org (Yakov Shafranovich) Date: Tue, 9 Jan 2024 21:12:50 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2] In-Reply-To: <2MTlGUzO3WSUMCNjTsxgKQQk5XCHrIQqVf4HH-jQ1E8=.6f7d081c-a4e6-4007-a9e9-77c7893b65d8@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>

<2MTlGUzO3WSUMCNjTsxgKQQk5XCHrIQqVf4HH-jQ1E8=.6f7d081c-a4e6-4007-a9e9-77c7893b65d8@github.com> Message-ID: On Wed, 22 Nov 2023 22:23:18 GMT, Yakov Shafranovich wrote: >> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 77: >> >>> 75: * >>> 76: * Whenever possible, {@linkplain ZipFile} should be used for parsing ZIP >>> 77: * archives since it correctly reads data from the central directory. >> >> I think it's okay to extend the existing API note to say that the stream may contain ZIP file entries that are not are not named in the central directory. I think I would replace the sentence "Additionally ..." with "Consequently, a ZipInputStream that reads from a ZIP file may read ZIP file entries that are not in the ZIP file's central directory". >> >> The sentence "This class might also fail to properly parse ZIP archives that have prepended data" will confuse readers as it hints of unreliability in scenarios and begs too many questions on where the data is prepended. So I think drop this unless you can come up with something better. >> >> Replacing the sentence "ZipFile may be used ..." is okay but I don't think the proposed text works. The API note starts with text to say that a ZipInputStream doesn't read the CEN so saying "correctly reads from the central directory" is very confusing. ZipInputStream is a JDK 1.1 era API, it is what it is and would be disruptive to deprecate. > > Thank you, I will work on this I updated the file ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1446615096 From duke at openjdk.org Tue Jan 9 21:12:51 2024 From: duke at openjdk.org (Yakov Shafranovich) Date: Tue, 9 Jan 2024 21:12:51 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2] In-Reply-To: <9O4rzgUxgatkIKu8aCng2w9ypg3Gpao185Osd6nzZws=.de9a68c6-577b-40fd-9e9e-32e12873f919@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com> <9O4rzgUxgatkIKu8aCng2w9ypg3Gpao185Osd6nzZws=.de9a68c6-577b-40fd-9e9e-32e12873f919@github.com> Message-ID: On Mon, 13 Nov 2023 18:11:12 GMT, Alan Bateman wrote: >> That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings? Would it make sense to split the rest of the changes in this PR from the zipfs changes since that's going to be a bigger undertaking? > >> That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings? Would it make sense to split the rest of the changes in this PR from the zipfs changes since that's going to be a bigger undertaking? > > Yes, I think it should be separated, and it would be nice to drop the changes to jdk.zipfs from this PR. If/when this documentation is written then it describe the "/" character and the synthesized links that are "." and "..", which can lead to documentation that a zip file with name elements of "." or ".." cannot be opened as a file system. Removed from this PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1446615201 From duke at openjdk.org Thu Jan 11 03:09:35 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jan 2024 03:09:35 GMT Subject: Withdrawn: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15264 From varadam at openjdk.org Thu Jan 11 04:47:26 2024 From: varadam at openjdk.org (Varada M) Date: Thu, 11 Jan 2024 04:47:26 GMT Subject: RFR: JDK-8323276: StressDirListings.java fails on AIX Message-ID: The delay in response has caused an incomplete test and timeout error. Setting the TCP_NODELAY socket option to 1 by the property sun.net.httpserver.nodelay solves the issue. JBS Issue : [JDK-8323276](https://bugs.openjdk.org/browse/JDK-8323276) ------------- Commit messages: - JDK-8323276 - StressDirListings.java fails on AIX Changes: https://git.openjdk.org/jdk/pull/17363/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17363&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323276 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17363.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17363/head:pull/17363 PR: https://git.openjdk.org/jdk/pull/17363 From jpai at openjdk.org Thu Jan 11 07:25:22 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Jan 2024 07:25:22 GMT Subject: RFR: JDK-8323276: StressDirListings.java fails on AIX In-Reply-To: References: Message-ID: <84jpxtvCaB7TwPEWopSpJ0HFrlwPZ2lCNuniim3qTSg=.dcf9347e-151d-4a35-9978-3727f4590eaa@github.com> On Thu, 11 Jan 2024 04:41:58 GMT, Varada M wrote: > The delay in response has caused an incomplete test and timeout error. Setting the TCP_NODELAY socket option to 1 by the property sun.net.httpserver.nodelay solves the issue. > > JBS Issue : [JDK-8323276](https://bugs.openjdk.org/browse/JDK-8323276) The change looks OK to me. We set this property in a couple of other tests for similar reasons. I've run this change against our internal CI (with a test repeat of 50) and the test continues to pass. Please update the copyright year to 2024 from 2022. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17363#pullrequestreview-1814828541 From varadam at openjdk.org Thu Jan 11 08:50:51 2024 From: varadam at openjdk.org (Varada M) Date: Thu, 11 Jan 2024 08:50:51 GMT Subject: RFR: JDK-8323276: StressDirListings.java fails on AIX [v2] In-Reply-To: References: Message-ID: <6F6OZQLCbnrAs6N1GXQ2ClJoTnJTuEbEGh1XDNooYjQ=.f6894cbc-bb92-4d69-8b40-d29c0fd0d436@github.com> > The delay in response has caused an incomplete test and timeout error. Setting the TCP_NODELAY socket option to 1 by the property sun.net.httpserver.nodelay solves the issue. > > JBS Issue : [JDK-8323276](https://bugs.openjdk.org/browse/JDK-8323276) Varada M has updated the pull request incrementally with one additional commit since the last revision: JDK-8323276: StressDirListings.java fails on AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17363/files - new: https://git.openjdk.org/jdk/pull/17363/files/3c2a8adb..7855d90c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17363&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17363&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17363.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17363/head:pull/17363 PR: https://git.openjdk.org/jdk/pull/17363 From varadam at openjdk.org Thu Jan 11 08:53:25 2024 From: varadam at openjdk.org (Varada M) Date: Thu, 11 Jan 2024 08:53:25 GMT Subject: RFR: JDK-8323276: StressDirListings.java fails on AIX In-Reply-To: References: Message-ID: <6dISmlPSZAsv_Fmdk4x1yu_4Tvrl5YBDEyaAdjgIbHo=.2441e049-50a5-42ef-8efc-1d7933e1d471@github.com> On Thu, 11 Jan 2024 04:41:58 GMT, Varada M wrote: > The delay in response has caused an incomplete test and timeout error. Setting the TCP_NODELAY socket option to 1 by the property sun.net.httpserver.nodelay solves the issue. > > JBS Issue : [JDK-8323276](https://bugs.openjdk.org/browse/JDK-8323276) Updated the copyright year. Thank you ------------- PR Comment: https://git.openjdk.org/jdk/pull/17363#issuecomment-1886646969 From dfuchs at openjdk.org Thu Jan 11 10:33:24 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 11 Jan 2024 10:33:24 GMT Subject: RFR: JDK-8323276: StressDirListings.java fails on AIX [v2] In-Reply-To: <6F6OZQLCbnrAs6N1GXQ2ClJoTnJTuEbEGh1XDNooYjQ=.f6894cbc-bb92-4d69-8b40-d29c0fd0d436@github.com> References: <6F6OZQLCbnrAs6N1GXQ2ClJoTnJTuEbEGh1XDNooYjQ=.f6894cbc-bb92-4d69-8b40-d29c0fd0d436@github.com> Message-ID: <0ZtVX1Ht0xKqzxhHwD04N2QVGWBK9v3s26UNepP-LEM=.e71dbbfe-b1a0-41ae-9105-271490f73069@github.com> On Thu, 11 Jan 2024 08:50:51 GMT, Varada M wrote: >> The delay in response has caused an incomplete test and timeout error. Setting the TCP_NODELAY socket option to 1 by the property sun.net.httpserver.nodelay solves the issue. >> >> JBS Issue : [JDK-8323276](https://bugs.openjdk.org/browse/JDK-8323276) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323276: StressDirListings.java fails on AIX LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17363#pullrequestreview-1815206737 From varadam at openjdk.org Thu Jan 11 12:20:33 2024 From: varadam at openjdk.org (Varada M) Date: Thu, 11 Jan 2024 12:20:33 GMT Subject: Integrated: JDK-8323276: StressDirListings.java fails on AIX In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 04:41:58 GMT, Varada M wrote: > The delay in response has caused an incomplete test and timeout error. Setting the TCP_NODELAY socket option to 1 by the property sun.net.httpserver.nodelay solves the issue. > > JBS Issue : [JDK-8323276](https://bugs.openjdk.org/browse/JDK-8323276) This pull request has now been integrated. Changeset: e5aed6be Author: Varada M Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/e5aed6be7a184a86a32fa671d48e0781fab54183 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8323276: StressDirListings.java fails on AIX Reviewed-by: jpai, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/17363 From duke at openjdk.org Thu Jan 11 18:16:38 2024 From: duke at openjdk.org (Bernd) Date: Thu, 11 Jan 2024 18:16:38 GMT Subject: RFR: JDK-8323276: StressDirListings.java fails on AIX [v2] In-Reply-To: <6F6OZQLCbnrAs6N1GXQ2ClJoTnJTuEbEGh1XDNooYjQ=.f6894cbc-bb92-4d69-8b40-d29c0fd0d436@github.com> References: <6F6OZQLCbnrAs6N1GXQ2ClJoTnJTuEbEGh1XDNooYjQ=.f6894cbc-bb92-4d69-8b40-d29c0fd0d436@github.com> Message-ID: On Thu, 11 Jan 2024 08:50:51 GMT, Varada M wrote: >> The delay in response has caused an incomplete test and timeout error. Setting the TCP_NODELAY socket option to 1 by the property sun.net.httpserver.nodelay solves the issue. >> >> JBS Issue : [JDK-8323276](https://bugs.openjdk.org/browse/JDK-8323276) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323276: StressDirListings.java fails on AIX BTW what would http server use Nagel algorithm by default and why is it affecting aix and this test so much. Is there maybe buffering or flushing missing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17363#issuecomment-1887707997 From jpai at openjdk.org Fri Jan 12 14:02:30 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Jan 2024 14:02:30 GMT Subject: RFR: 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface Message-ID: Can I please get a review of this change which removes unused code from `sun.net.www.protocol.jar.URLJarFile` and removes `sun.net.www.protocol.jar.URLJarFileCallBack`? As noted in the linked issue https://bugs.openjdk.org/browse/JDK-8323645 the `sun.net.www.protocol.jar.URLJarFileCallBack` was relevant and used only by Java Plugin code (the "deploy" module in JDK 8) which hasn't been in the JDK for several releases now. Effectively this interface and its sole usage in an internal class of the JDK has been a leftover. The commit in this PR removes that leftover code. No new tests have been added, given the nature of this change. tier1, tier2, tier3 continue to pass with this change. ------------- Commit messages: - 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface Changes: https://git.openjdk.org/jdk/pull/17396/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17396&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323645 Stats: 118 lines in 2 files changed: 1 ins; 91 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/17396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17396/head:pull/17396 PR: https://git.openjdk.org/jdk/pull/17396 From jpai at openjdk.org Sat Jan 13 08:46:50 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Jan 2024 08:46:50 GMT Subject: RFR: 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which removes unused code from `sun.net.www.protocol.jar.URLJarFile` and removes `sun.net.www.protocol.jar.URLJarFileCallBack`? > > As noted in the linked issue https://bugs.openjdk.org/browse/JDK-8323645 the `sun.net.www.protocol.jar.URLJarFileCallBack` was relevant and used only by Java Plugin code (the "deploy" module in JDK 8) which hasn't been in the JDK for several releases now. Effectively this interface and its sole usage in an internal class of the JDK has been a leftover. > > The commit in this PR removes that leftover code. No new tests have been added, given the nature of this change. tier1, tier2, tier3 continue to pass with this change. Jaikiran Pai 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. The pull request contains two additional commits since the last revision: - merge latest from master branch - 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17396/files - new: https://git.openjdk.org/jdk/pull/17396/files/a7bfb6b4..80dd62a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17396&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17396&range=00-01 Stats: 5328 lines in 70 files changed: 3154 ins; 1838 del; 336 mod Patch: https://git.openjdk.org/jdk/pull/17396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17396/head:pull/17396 PR: https://git.openjdk.org/jdk/pull/17396 From alanb at openjdk.org Sat Jan 13 09:31:18 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 13 Jan 2024 09:31:18 GMT Subject: RFR: 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface [v2] In-Reply-To: References:

Message-ID: On Thu, 18 Jan 2024 09:29:11 GMT, Magnus Ihse Bursie wrote: > Thanks! When this has been integrated, I can take a shot at the missorted `default`s. Thanks, I could've done that myself, but decided not to. You see, `default` should ideally be a [sole] modifier on a method: all other modifiers of a `default` method should be deleted. I'm not sure that reaching such an ideal would be welcomed. Whatever you decide to do, be prepared to work manually. `bin/blessed-modifier-order.sh` is simple and robust but not specific. You'll have to carefully sift through other missortings it finds. [sole]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117398.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/17468#issuecomment-1898162068 From prappo at openjdk.org Thu Jan 18 22:31:38 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 18 Jan 2024 22:31:38 GMT Subject: Integrated: 8324053: Use the blessed modifier order for sealed in java.base In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. This pull request has now been integrated. Changeset: 9efdd242 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/9efdd242fb40a8270e489cc071ff1c891878e24f Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 mod 8324053: Use the blessed modifier order for sealed in java.base Reviewed-by: naoto, darcy, ihse, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/17468 From acobbs at openjdk.org Fri Jan 19 15:38:39 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 19 Jan 2024 15:38:39 GMT Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer [v2] In-Reply-To: References: Message-ID: > Please review several fixes and improvements to the `this-escape` lint warning analyzer. > > The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design. > > Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below. > > The changes are summarized here: > > #### 1. Generalize how we categorize references > > The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape". > > Previously the `Ref` categories were: > * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed > * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed > * `VarRef` - A local variable or method parameter currently in scope > * `ExprRef` - An object reference sitting on top of the Java execution stack > * `YieldRef` - The current switch expression's yield value(s) > * `ReturnRef` - The current method's return value(s) > > For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced). > > The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference. > > In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect". > > As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`. > > #### 2. Track the types of all references > > By keeping track of the actual type of... Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into JDK-8317376 - Merge branch 'master' into JDK-8317376 - Merge branch 'master' into JDK-8317376 - Javadoc++ - Merge branch 'master' into JDK-8317376 - Several improvements to the 'this' escape analyzer. - Track direct, indirect, and outer references for all Ref types. - Keep type information about all references to improve tracking precision. - Track enhanced for() invocations of iterator(), hasNext(), and next(). - Don't report an escape of a non-public outer instances as a leak. - Fix omitted tracking of references from newly instantiated instances. - Fix omitted tracking of leaks via lambda return values. - Remove unneccesary suppressions of this-escape lint warning. ------------- Changes: https://git.openjdk.org/jdk/pull/16208/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16208&range=01 Stats: 871 lines in 20 files changed: 513 ins; 148 del; 210 mod Patch: https://git.openjdk.org/jdk/pull/16208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16208/head:pull/16208 PR: https://git.openjdk.org/jdk/pull/16208 From duke at openjdk.org Sat Jan 20 19:03:35 2024 From: duke at openjdk.org (Jacob Henner) Date: Sat, 20 Jan 2024 19:03:35 GMT Subject: RFR: 8318599: HttpURLConnection cache issues leading to crashes in JGSS w/ native GSS introduced by 8303809 In-Reply-To: References: Message-ID: On Tue, 24 Oct 2023 15:33:34 GMT, Michael McMahon wrote: > Hi, > > This fix resolves a VM crash issue caused by a memory use after free in JGSS native code. The cause is the `java.net.HttpURLConnection` implementation which is incorrectly caching GSS context objects which end up being used and reused by multiple threads in parallel, and in fact should only be used once, with separate instances for separate requests (requiring authentication). The fix is very simple and is just that the NegotiateAuthentication class needs to be marked as non-cacheable. A test is not included here as it requires testing against real servers that aren't publicly accessible. > > Thanks, > Michael Is this fix expected to be backported to the LTS versions that were affected when https://bugs.openjdk.org/browse/JDK-8303809 was backported? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16347#issuecomment-1902239052 From Alan.Bateman at oracle.com Mon Jan 22 07:18:24 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Jan 2024 07:18:24 +0000 Subject: Does anyone have context on jdk.httpserver? In-Reply-To: References: Message-ID: <45a03625-12fb-4c6b-8b67-18c4fffad732@oracle.com> On 21/01/2024 20:18, Ethan McCue wrote: > Hi all, > > Elliot[1] and I have been digging into the HTTP(S) server > implementation provided by the jdk.httpserver module. > > It hasn't taken long to notice that the provided implementation > is...lacking. Both in performance, as it places extremely low and > errors out on benchmarks [2][3], and in polish, as doing relatively > simple tasks like printing out the result of > HttpExchange#getRequestHeaders()?does not actually include the headers > in the output. > > But, the actual API isn't wretched. The overall design (with a Filter > chain and a mutable "out" object for responses) is reminiscent of > Servlets and there is an SPI hook to provide custom server > implementations. And unlike the jwebserver tool, which is built on > this, there isn't a "for education purposes only" sign anywhere and it > is part of an exported and supposedly supported module. > > All that is to ask - does anyone on this mailing list have any > historical context on this? Why was it added to the JDK, what were the > goals of its implementation, are there any records of the decision > process behind its design? > > Separately is there any appetite for improving the performance of the > built-in server implementation? The history on this is the web services client (meaning JAX-WS), added in Java 6. A HTTP server was required to support web services "callbacks". As it turned out, having a basic HTTP server in the JDK is very useful for writing tests and very useful at reducing the "getting startup" effort to serve up a web page. The HTTP server was never meant to be feature rich with performance on par with other HTTP servers. However, it does have a service provider interface (SPI) so alternative implementations can be used (there are at least 3 full featured HTTP servers that implement the SPI). More recently, JEP 408 [1] added a command line interface to make it easy to get started. It also added to the API to make it easy to create and customize. You've found that so you have some context on what the HTTP server is intended for now. The net-dev mailing list is the mailing list to use. -Alan [1] https://openjdk.org/jeps/408 From rengels at ix.netcom.com Mon Jan 22 08:43:48 2024 From: rengels at ix.netcom.com (Robert Engels) Date: Mon, 22 Jan 2024 02:43:48 -0600 Subject: Does anyone have context on jdk.httpserver? In-Reply-To: <45a03625-12fb-4c6b-8b67-18c4fffad732@oracle.com> References: <45a03625-12fb-4c6b-8b67-18c4fffad732@oracle.com> Message-ID: <1CF18B51-7710-4035-965B-73D08C09CEC7@ix.netcom.com> See github.com/robaho/httpserver for a more capable fork of the JDK code. Would love to create a PR to move the core changes back into the JDK but the net-dev folks don?t seem to be interested > On Jan 22, 2024, at 1:18?AM, Alan Bateman wrote: > ?On 21/01/2024 20:18, Ethan McCue wrote: >> Hi all, >> >> Elliot[1] and I have been digging into the HTTP(S) server implementation provided by the jdk.httpserver module. >> >> It hasn't taken long to notice that the provided implementation is...lacking. Both in performance, as it places extremely low and errors out on benchmarks [2][3], and in polish, as doing relatively simple tasks like printing out the result of HttpExchange#getRequestHeaders() does not actually include the headers in the output. >> >> But, the actual API isn't wretched. The overall design (with a Filter chain and a mutable "out" object for responses) is reminiscent of Servlets and there is an SPI hook to provide custom server implementations. And unlike the jwebserver tool, which is built on this, there isn't a "for education purposes only" sign anywhere and it is part of an exported and supposedly supported module. >> >> All that is to ask - does anyone on this mailing list have any historical context on this? Why was it added to the JDK, what were the goals of its implementation, are there any records of the decision process behind its design? >> >> Separately is there any appetite for improving the performance of the built-in server implementation? > > The history on this is the web services client (meaning JAX-WS), added in Java 6. A HTTP server was required to support web services "callbacks". > > As it turned out, having a basic HTTP server in the JDK is very useful for writing tests and very useful at reducing the "getting startup" effort to serve up a web page. The HTTP server was never meant to be feature rich with performance on par with other HTTP servers. However, it does have a service provider interface (SPI) so alternative implementations can be used (there are at least 3 full featured HTTP servers that implement the SPI). > > More recently, JEP 408 [1] added a command line interface to make it easy to get started. It also added to the API to make it easy to create and customize. You've found that so you have some context on what the HTTP server is intended for now. > > The net-dev mailing list is the mailing list to use. > > -Alan > > [1] https://openjdk.org/jeps/408 From Alan.Bateman at oracle.com Mon Jan 22 09:08:19 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Jan 2024 09:08:19 +0000 Subject: Does anyone have context on jdk.httpserver? In-Reply-To: <1CF18B51-7710-4035-965B-73D08C09CEC7@ix.netcom.com> References: <45a03625-12fb-4c6b-8b67-18c4fffad732@oracle.com> <1CF18B51-7710-4035-965B-73D08C09CEC7@ix.netcom.com> Message-ID: On 22/01/2024 08:43, Robert Engels wrote: > See github.com/robaho/httpserver for a more capable fork of the JDK code. > > Would love to create a PR to move the core changes back into the JDK but the net-dev folks don?t seem to be interested As I recall, it wasn't really possible to do any assessment because the "contribution" wasn't covered by the OCA. In addition, I think you said in one of the mails that it includes code from another project (for websocket or HTTP upgrade?) and it's a big deal to have to import and work through the license issues with 3rd party code. At a high level it seems reasonable to update the HTTP server implementation to work better with virtual threads but updating it to be a more fully featured HTTP server goes beyond what this HTTP server was/is intended for. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Mon Jan 22 09:17:01 2024 From: rengels at ix.netcom.com (Robert Engels) Date: Mon, 22 Jan 2024 03:17:01 -0600 Subject: Does anyone have context on jdk.httpserver? In-Reply-To: References: Message-ID: <2588DF2C-D0FE-4B7E-BB48-D98B83D238B9@ix.netcom.com> That is reasonable - but somehow I missed that reply (regarding OCA, etc). More than willing to sign the OCA for a PR. As to the code from another project - clearly that wouldn?t work - so I was thinking more about changes that would allow someone to supply a websockets impl outside of the jdk. Anyway, thanks for the update - I?ll need to go back and see why I missed it - I thought I had just been ignored :) > On Jan 22, 2024, at 3:08?AM, Alan Bateman wrote: > > ? On 22/01/2024 08:43, Robert Engels wrote: >> See github.com/robaho/httpserver for a more capable fork of the JDK code. >> >> Would love to create a PR to move the core changes back into the JDK but the net-dev folks don?t seem to be interested > > As I recall, it wasn't really possible to do any assessment because the "contribution" wasn't covered by the OCA. In addition, I think you said in one of the mails that it includes code from another project (for websocket or HTTP upgrade?) and it's a big deal to have to import and work through the license issues with 3rd party code. > > At a high level it seems reasonable to update the HTTP server implementation to work better with virtual threads but updating it to be a more fully featured HTTP server goes beyond what this HTTP server was/is intended for. > > -Alan > > From dclarke at openjdk.org Tue Jan 23 12:45:34 2024 From: dclarke at openjdk.org (Darragh Clarke) Date: Tue, 23 Jan 2024 12:45:34 GMT Subject: RFR: 8314164: java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails intermittently in timeout Message-ID: Currently `HttpURLConnectionExpectContinueTest` fails intermittently with a `SocketTimeoutException`. The connection timeout that is currently set to `1000` isn't actually needed for the purpose of the test so it should be more stable if the timeout is removed entirely. I've tested this change for stability it seems reliable. ------------- Commit messages: - removed connectTimeout Changes: https://git.openjdk.org/jdk/pull/17535/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17535&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314164 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17535.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17535/head:pull/17535 PR: https://git.openjdk.org/jdk/pull/17535 From dfuchs at openjdk.org Tue Jan 23 13:14:28 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Jan 2024 13:14:28 GMT Subject: RFR: 8314164: java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails intermittently in timeout In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 12:40:10 GMT, Darragh Clarke wrote: > Currently `HttpURLConnectionExpectContinueTest` fails intermittently with a `SocketTimeoutException`. > > The connection timeout that is currently set to `1000` isn't actually needed for the purpose of the test so it should be more stable if the timeout is removed entirely. > > I've tested this change for stability it seems reliable. Removing the connection timeout seems to be the best route to increase the stability of this test. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17535#pullrequestreview-1838760180 From djelinski at openjdk.org Tue Jan 23 13:30:26 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Jan 2024 13:30:26 GMT Subject: RFR: 8314164: java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails intermittently in timeout In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 12:40:10 GMT, Darragh Clarke wrote: > Currently `HttpURLConnectionExpectContinueTest` fails intermittently with a `SocketTimeoutException`. > > The connection timeout that is currently set to `1000` isn't actually needed for the purpose of the test so it should be more stable if the timeout is removed entirely. > > I've tested this change for stability it seems reliable. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17535#pullrequestreview-1838792784 From djelinski at openjdk.org Tue Jan 23 13:48:33 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Jan 2024 13:48:33 GMT Subject: RFR: 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out Message-ID: The test was occasionally failing with TestNG timeout. When a TestNG test times out, TestNG interrupts the test thread, and starts another test case in a new thread. The timeout is invisible to JTReg, and the timeout failure handlers are not run. This PR removes the TestNG timeout. It also removes `-ea -esa` from the test command line (the test does not use `assert`), and reduces the amount of synchronization objects used. I verified that the timeouts are now handled by JTReg. The test still passes. ------------- Commit messages: - Remove TestNG timeout Changes: https://git.openjdk.org/jdk/pull/17536/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17536&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8223696 Stats: 24 lines in 1 file changed: 5 ins; 15 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17536/head:pull/17536 PR: https://git.openjdk.org/jdk/pull/17536 From dclarke at openjdk.org Tue Jan 23 14:10:35 2024 From: dclarke at openjdk.org (Darragh Clarke) Date: Tue, 23 Jan 2024 14:10:35 GMT Subject: Integrated: 8314164: java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails intermittently in timeout In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 12:40:10 GMT, Darragh Clarke wrote: > Currently `HttpURLConnectionExpectContinueTest` fails intermittently with a `SocketTimeoutException`. > > The connection timeout that is currently set to `1000` isn't actually needed for the purpose of the test so it should be more stable if the timeout is removed entirely. > > I've tested this change for stability it seems reliable. This pull request has now been integrated. Changeset: fbaaac63 Author: Darragh Clarke URL: https://git.openjdk.org/jdk/commit/fbaaac63d4ae8d7cc0ec02ab4b5a934824d1fec1 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8314164: java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails intermittently in timeout Reviewed-by: dfuchs, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/17535 From dfuchs at openjdk.org Tue Jan 23 14:49:31 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Jan 2024 14:49:31 GMT Subject: RFR: 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 13:15:46 GMT, Daniel Jeli?ski wrote: > The test was occasionally failing with TestNG timeout. When a TestNG test times out, TestNG interrupts the test thread, and starts another test case in a new thread. The timeout is invisible to JTReg, and the timeout failure handlers are not run. > > This PR removes the TestNG timeout. It also removes `-ea -esa` from the test command line (the test does not use `assert`), and reduces the amount of synchronization objects used. > > I verified that the timeouts are now handled by JTReg. The test still passes. Changes requested by dfuchs (Reviewer). test/jdk/java/net/httpclient/MaxStreams.java line 208: > 206: > 207: is.readAllBytes(); > 208: int c = counter.getAndIncrement(); That looks mostly fine, but it leaves a race condition where `counter.set(0)` could en up being executed after the next call to the test method happens. I believe that's what the `canStartTestRun` semaphore was trying to prevent. Instead of trying to acquire the semaphore at the beginning of the next test run, maybe we should use it (or some other primitive) to make sure that the current test method doesn't finish before `counter.set(0)` has been executed? ------------- PR Review: https://git.openjdk.org/jdk/pull/17536#pullrequestreview-1838974313 PR Review Comment: https://git.openjdk.org/jdk/pull/17536#discussion_r1463392445 From djelinski at openjdk.org Tue Jan 23 15:16:31 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Jan 2024 15:16:31 GMT Subject: RFR: 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out In-Reply-To: References:

Message-ID: On Tue, 23 Jan 2024 14:46:54 GMT, Daniel Fuchs wrote: >> The test was occasionally failing with TestNG timeout. When a TestNG test times out, TestNG interrupts the test thread, and starts another test case in a new thread. The timeout is invisible to JTReg, and the timeout failure handlers are not run. >> >> This PR removes the TestNG timeout. It also removes `-ea -esa` from the test command line (the test does not use `assert`), and reduces the amount of synchronization objects used. >> >> I verified that the timeouts are now handled by JTReg. The test still passes. > > test/jdk/java/net/httpclient/MaxStreams.java line 208: > >> 206: >> 207: is.readAllBytes(); >> 208: int c = counter.getAndIncrement(); > > That looks mostly fine, but it leaves a race condition where `counter.set(0)` could en up being executed after the next call to the test method happens. I believe that's what the `canStartTestRun` semaphore was trying to prevent. Instead of trying to acquire the semaphore at the beginning of the next test run, maybe we should use it (or some other primitive) to make sure that the current test method doesn't finish before `counter.set(0)` has been executed? I moved the counter.set line before sendResponseHeaders. This should take care of the necessary synchronization: the server sets the counter to zero before sending the response, the response needs to be received before the test completes, the test needs to complete before another one is started. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17536#discussion_r1463432958 From dfuchs at openjdk.org Tue Jan 23 15:29:31 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Jan 2024 15:29:31 GMT Subject: RFR: 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 13:15:46 GMT, Daniel Jeli?ski wrote: > The test was occasionally failing with TestNG timeout. When a TestNG test times out, TestNG interrupts the test thread, and starts another test case in a new thread. The timeout is invisible to JTReg, and the timeout failure handlers are not run. > > This PR removes the TestNG timeout. It also removes `-ea -esa` from the test command line (the test does not use `assert`), and reduces the amount of synchronization objects used. > > I verified that the timeouts are now handled by JTReg. The test still passes. test/jdk/java/net/httpclient/MaxStreams.java line 220: > 218: // client issues MAX_STREAMS + 3 requests in total > 219: // but server should only see MAX_STREAMS + 2 in total. One is rejected by client > 220: // counter c captured before increment so final value is MAX_STREAMS + 1 Can we keep/add a trace here to say that counter is reset to 0? Otherwise looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17536#discussion_r1463453547 From dfuchs at openjdk.org Wed Jan 24 09:18:27 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 24 Jan 2024 09:18:27 GMT Subject: RFR: 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out [v2] In-Reply-To: References:

Message-ID: On Wed, 24 Jan 2024 09:11:38 GMT, Daniel Jeli?ski wrote: >> The test was occasionally failing with TestNG timeout. When a TestNG test times out, TestNG interrupts the test thread, and starts another test case in a new thread. The timeout is invisible to JTReg, and the timeout failure handlers are not run. >> >> This PR removes the TestNG timeout. It also removes `-ea -esa` from the test command line (the test does not use `assert`), and reduces the amount of synchronization objects used. >> >> I verified that the timeouts are now handled by JTReg. The test still passes. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Reintroduce log Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17536#pullrequestreview-1840859745 From djelinski at openjdk.org Wed Jan 24 09:11:40 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Jan 2024 09:11:40 GMT Subject: RFR: 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out [v2] In-Reply-To: References:

Message-ID: On Tue, 23 Jan 2024 15:26:53 GMT, Daniel Fuchs wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Reintroduce log > > test/jdk/java/net/httpclient/MaxStreams.java line 220: > >> 218: // client issues MAX_STREAMS + 3 requests in total >> 219: // but server should only see MAX_STREAMS + 2 in total. One is rejected by client >> 220: // counter c captured before increment so final value is MAX_STREAMS + 1 > > Can we keep/add a trace here to say that counter is reset to 0? > Otherwise looks good. Log added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17536#discussion_r1464560701 From djelinski at openjdk.org Wed Jan 24 09:11:38 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Jan 2024 09:11:38 GMT Subject: RFR: 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out [v2] In-Reply-To: References: Message-ID: > The test was occasionally failing with TestNG timeout. When a TestNG test times out, TestNG interrupts the test thread, and starts another test case in a new thread. The timeout is invisible to JTReg, and the timeout failure handlers are not run. > > This PR removes the TestNG timeout. It also removes `-ea -esa` from the test command line (the test does not use `assert`), and reduces the amount of synchronization objects used. > > I verified that the timeouts are now handled by JTReg. The test still passes. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Reintroduce log ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17536/files - new: https://git.openjdk.org/jdk/pull/17536/files/55db7ea8..ef74f79d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17536&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17536&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17536/head:pull/17536 PR: https://git.openjdk.org/jdk/pull/17536 From alanb at openjdk.org Thu Jan 25 07:26:26 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Jan 2024 07:26:26 GMT Subject: RFR: 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface [v2] In-Reply-To: References:

Message-ID: On Sat, 13 Jan 2024 08:46:50 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes unused code from `sun.net.www.protocol.jar.URLJarFile` and removes `sun.net.www.protocol.jar.URLJarFileCallBack`? >> >> As noted in the linked issue https://bugs.openjdk.org/browse/JDK-8323645 the `sun.net.www.protocol.jar.URLJarFileCallBack` was relevant and used only by Java Plugin code (the "deploy" module in JDK 8) which hasn't been in the JDK for several releases now. Effectively this interface and its sole usage in an internal class of the JDK has been a leftover. >> >> The commit in this PR removes that leftover code. No new tests have been added, given the nature of this change. tier1, tier2, tier3 continue to pass with this change. > > Jaikiran Pai 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. The pull request contains two additional commits since the last revision: > > - merge latest from master branch > - 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface Thank you Alan and Daniel for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17396#issuecomment-1909753226 From jpai at openjdk.org Thu Jan 25 09:39:41 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 25 Jan 2024 09:39:41 GMT Subject: Integrated: 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 13:56:51 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes unused code from `sun.net.www.protocol.jar.URLJarFile` and removes `sun.net.www.protocol.jar.URLJarFileCallBack`? > > As noted in the linked issue https://bugs.openjdk.org/browse/JDK-8323645 the `sun.net.www.protocol.jar.URLJarFileCallBack` was relevant and used only by Java Plugin code (the "deploy" module in JDK 8) which hasn't been in the JDK for several releases now. Effectively this interface and its sole usage in an internal class of the JDK has been a leftover. > > The commit in this PR removes that leftover code. No new tests have been added, given the nature of this change. tier1, tier2, tier3 continue to pass with this change. This pull request has now been integrated. Changeset: 9d1a6d14 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/9d1a6d14846bb1f76ca7258452b3b3f8e3e8b223 Stats: 118 lines in 2 files changed: 1 ins; 91 del; 26 mod 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface Reviewed-by: alanb, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/17396 From jpai at openjdk.org Thu Jan 25 13:52:48 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 25 Jan 2024 13:52:48 GMT Subject: RFR: JDK-8323276: StressDirListings.java fails on AIX [v2] In-Reply-To: <6F6OZQLCbnrAs6N1GXQ2ClJoTnJTuEbEGh1XDNooYjQ=.f6894cbc-bb92-4d69-8b40-d29c0fd0d436@github.com> References: <6F6OZQLCbnrAs6N1GXQ2ClJoTnJTuEbEGh1XDNooYjQ=.f6894cbc-bb92-4d69-8b40-d29c0fd0d436@github.com> Message-ID: On Thu, 11 Jan 2024 08:50:51 GMT, Varada M wrote: >> The delay in response has caused an incomplete test and timeout error. Setting the TCP_NODELAY socket option to 1 by the property sun.net.httpserver.nodelay solves the issue. >> >> JBS Issue : [JDK-8323276](https://bugs.openjdk.org/browse/JDK-8323276) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323276: StressDirListings.java fails on AIX Hello Bernd, > BTW what would http server use Nagel algorithm by default and why is it affecting aix and this test so much. Is there maybe buffering or flushing missing? I don't know about this specific AIX setup where this was causing an issue. However, in the past we have seen this happen in some other tests too on Linux (https://bugs.openjdk.org/browse/JDK-8294610). While investigating that other test, we had noticed that in a situation where there are a lot of HTTP request/response between the client and the server (like in this current StressDirListings test) and if the server responds to each request with relatively small content, then at the TCP layer on the client side, the ACKs aren't sent back to the server immediately. Instead, the (TCP) ACKs are delayed by the client's host to the server's host. This then causes the server's host to wait for the ACKs before pushing the next set of data packets to the client, even though the application layer HTTP server keeps writing out content. This ultimately boils down to what's explained in the description of https://bugs.openjdk.org/browse/JDK-6968351. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17363#issuecomment-1910258565 From djelinski at openjdk.org Thu Jan 25 22:04:39 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Jan 2024 22:04:39 GMT Subject: Integrated: 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out In-Reply-To: References: Message-ID: <1Rpy-9NuF9CF7ZdQBBizHpY7sbH_Z5-0cdF7BHMktdE=.48e4b0d0-9431-485c-84b3-743b45864cbf@github.com> On Tue, 23 Jan 2024 13:15:46 GMT, Daniel Jeli?ski wrote: > The test was occasionally failing with TestNG timeout. When a TestNG test times out, TestNG interrupts the test thread, and starts another test case in a new thread. The timeout is invisible to JTReg, and the timeout failure handlers are not run. > > This PR removes the TestNG timeout. It also removes `-ea -esa` from the test command line (the test does not use `assert`), and reduces the amount of synchronization objects used. > > I verified that the timeouts are now handled by JTReg. The test still passes. This pull request has now been integrated. Changeset: 95310eab Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/95310eab6ce73512b1afc0a7a26a396dd7b6cb7c Stats: 25 lines in 1 file changed: 6 ins; 15 del; 4 mod 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/17536 From duke at openjdk.org Sat Jan 27 17:15:40 2024 From: duke at openjdk.org (Bernd) Date: Sat, 27 Jan 2024 17:15:40 GMT Subject: RFR: JDK-8323276: StressDirListings.java fails on AIX [v2] In-Reply-To: <6F6OZQLCbnrAs6N1GXQ2ClJoTnJTuEbEGh1XDNooYjQ=.f6894cbc-bb92-4d69-8b40-d29c0fd0d436@github.com> References: <6F6OZQLCbnrAs6N1GXQ2ClJoTnJTuEbEGh1XDNooYjQ=.f6894cbc-bb92-4d69-8b40-d29c0fd0d436@github.com> Message-ID: On Thu, 11 Jan 2024 08:50:51 GMT, Varada M wrote: >> The delay in response has caused an incomplete test and timeout error. Setting the TCP_NODELAY socket option to 1 by the property sun.net.httpserver.nodelay solves the issue. >> >> JBS Issue : [JDK-8323276](https://bugs.openjdk.org/browse/JDK-8323276) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323276: StressDirListings.java fails on AIX ah maybe aix has not the nagel optimization which recognized full+partial packets (Minshall) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17363#issuecomment-1913263553