[teststabilization] RFR: 8226825: Replace wildcard address with loopback or local host in tests - part 19

Hi, Please find below a patch for: 8226825: Replace wildcard address with loopback or local host in tests - part 19 https://bugs.openjdk.java.net/browse/JDK-8226825 webrev: http://cr.openjdk.java.net/~dfuchs/jboes/webrev_8226825/webrev/ - Replaced wildcard address with loopback or localho

Re: [teststabilization] RFR: 8226825: Replace wildcard address with loopback or local host in tests - part 19

Hi, Thanks Brian and Chris for your comments! I incorporated the changes. Here's the updated webrev: http://cr.openjdk.java.net/~dfuchs/jboes/webrev_8226825/webrev.01/ Cheers, Julia On 26/06/2019 21:32, Chris Hegarty wrote: Julia, On 26 Jun 2019, at 18:33, Julia Boes wrote

RFR: 8185898: setRequestProperty(key, null) results in HTTP header without colon in request

Hi, Please find below a patch for: 8185898: setRequestProperty(key, null) results in HTTP header without colon in request https://bugs.openjdk.java.net/browse/JDK-8185898 According to RFC 2616 , message headers of a HTTP message must adhere to

Re: RFR: 8185898: setRequestProperty(key, null) results in HTTP header without colon in request

, -- daniel On 31/07/2019 11:56, Julia Boes wrote: Hi, Please find below a patch for: 8185898: setRequestProperty(key, null) results in HTTP header without colon in request https://bugs.openjdk.java.net/browse/JDK-8185898 According to RFC 2616 <https://tools.ietf.org/html/rfc2616#secti

Re: RFR: 8185898: setRequestProperty(key, null) results in HTTP header without colon in request

/jboes/8185898/webrev.4/ Regards, Julia On 06/08/2019 11:03, Julia Boes wrote: Hi Michael and Daniel, Thanks for your comments. I made the following changes to B8185898: - Added checks for URLConnection::getRequestProperties, ::getHeaderField(0), ::getHeaderFieldKey(0) - Included a test of

RFR: 8230000: some httpclients testng tests run zero test

Hi, Please find below a fix of three httpclient tests for which testng trivially passed without running any tests. In LineSubscribersAndSurrogatesTest and LineStreamsAndSurrogatesTest, the access modifier of the methods in question was changed to public. For AbstractThrowingPushPromises, th

Re: RFR: 8230000: some httpclients testng tests run zero test

Thanks for catching that, Aleksei! Updated webrev: http://cr.openjdk.java.net/~dfuchs/jboes/823/webrev.02/index.html Cheers, Julia On 23/08/2019 18:52, Daniel Fuchs wrote: Oh! Good catch Aleksei! In fact all three files are missing the comma. cheers, -- daniel On 23/08/2019 18:47, A

RFR: 8171405: java/net/URLConnection/ResendPostBody.java failed with "Error while cleaning up threads after test"

Hi, This fix involves a test that failed during thread cleanup. To address this, the ServerSocket is now being closed at the end and the server thread is joined. While at it, I removed some unnecessary whitespace. webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8171405/webrev.02/ bug report

Re: RFR: 8171405: java/net/URLConnection/ResendPostBody.java failed with "Error while cleaning up threads after test"

- Original message - From: Julia Boes Sent by: "net-dev" To: [email protected] Cc: Subject: [EXTERNAL] RFR: 8171405: java/net/URLConnection/ResendPostBody.java failed with "Error while cleaning up threads after test" Date: Thu, A

RFR: 8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST request

Hi, This fix addresses an issue in HttpClient when retrying a POST request over proxied HTTPS. In this case, the request body is stored in a PosterOutputStream poster, which is set to null in sun/net/www/protocol/http/HttpURLConnection::sendCONNECTRequest after the first request. The fix ad

Re: RFR: 8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST request

Thank you for reviewing, Vyom and Daniel. Daniel, would you push the change for me? Changeset: http://cr.openjdk.java.net/~jboes/webrevs/8209178/webrev.02/ Cheers, Julia On 25/09/2019 13:12, Daniel Fuchs wrote: Hi, On 24/09/2019 16:11, Julia Boes wrote: Hi, This fix addresses an issue

RFR: 8225499: InetSocketAddress::toString not friendly to IPv6 literal addresses

Hi, This fix improves the handling of IPv6 addresses in InetSocketAddress::toString. The implementation now encloses the IPv6 literal in brackets, which wasn't done previously. Example: new InetSocketAddress("::1", 80).toString() before: /0:0:0:0:0:0:0:1:80 after: /[0:0:0:0:0:0:0:1]:80 Addi

Re: RFR: 8225499: InetSocketAddress::toString not friendly to IPv6 literal addresses

should add a case where the InetAddress parameter passed to the constructor is null, as I think InetSocketAddress supports this. best regards, -- daniel On 09/10/2019 12:24, Julia Boes wrote: Hi, This fix improves the handling of IPv6 addresses in InetSocketAddress::toString. The

Re: RFR: 8225499: InetSocketAddress::toString not friendly to IPv6 literal addresses

: Looks good! best regards, -- daniel On 16/10/2019 10:38, Julia Boes wrote: Hi Daniel, Thanks for reviewing the change. I added a test case as per your suggestion. Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8225499/webrev.01/index.html Regards, Julia

RFR: 8231632: HttpURLConnection::usingProxy could specify that it may lazily evaluate the fact

Hi, This fix involves HttpURLConnection::usingProxy. Previously, the method would return true only once the connection was established (once the underlying socket was connected) and would switch back to false when as the input stream was fully read. The new implementation checks whether an ex

Re: RFR: 8231632: HttpURLConnection::usingProxy could specify that it may lazily evaluate the fact

ain a class field that is set to true in the connect method, as done in the updated webrev. Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231632/webrev.01/index.html Regards, Julia On 17/10/2019 10:21, Julia Boes wrote: Hi, This fix involves HttpURLConnection::usingProxy. Previously

Re: RFR: 8231632: HttpURLConnection::usingProxy could specify that it may lazily evaluate the fact

1) Maybe add @Override to `public boolean usingProxy()`. ( pre-existing issue ) 2) Maybe move the return on 3040 to a new line. Also use the curly braces consistently, or not at all ;-) That's right! Thanks for reviewing, Chris. I added those two changes. Updated webrev: http://cr.openjdk.j

Re: RFR: 8231632: HttpURLConnection::usingProxy could specify that it may lazily evaluate the fact

Thanks all! Here's CSR for the fix: https://bugs.openjdk.java.net/browse/JDK-8232600

Re: RFR: 8231632: HttpURLConnection::usingProxy could specify that it may lazily evaluate the fact

Hi, Based on Joe's feedback the specification change was turned from an @apiNote to an extension of the method description. See updated CSR: https://bugs.openjdk.java.net/browse/JDK-8232600 Thanks, Julia

Re: RFR: 8231632: HttpURLConnection::usingProxy could specify that it may lazily evaluate the fact

..and the updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231632/webrev.03/ On 29/10/2019 12:53, Julia Boes wrote: Hi, Based on Joe's feedback the specification change was turned from an @apiNote to an extension of the method description. See updated CSR:

RFR: 8232853: AuthenticationFilter.Cache::remove may throw ConcurrentModificationException

Hi, This fix addresses an issue in AuthenticationFilter.Cache::remove that can lead to a ConcurrentModificationException. The cache is implemented as LinkedList, the method iterates over the list and potentially removes items without using an iterator. To reproduce the bug, multiple requests

Re: RFR: 8232853: AuthenticationFilter.Cache::remove may throw ConcurrentModificationException

Thanks for the feedback everyone. It looks like Cache#remove can be fixed simply by using an explicit iterator and using iterator#remove instead of List#remove. Cache looks fishy in other ways, e.g. why does Cache#remove ignore authscheme? I changed the implementation to use an iterator in

Re: RFR: 8232853: AuthenticationFilter.Cache::remove may throw ConcurrentModificationException

Your new iterator approach looks good to me. one minor comment as you are using 'var' language construct the variable name 'au'  is not a meaning full name . Thanks for noting, Vyom. I changed the name to 'entry' (same webrev). Cheers, Julia

RFR: 8233185: HttpServer.stop() blocks indefinitely when called on dispatch thread

Hi, When HttpServer.stop(int delay) is called on the dispatcher thread of the server, the call blocks indefinitely as the thread is waiting for itself to die. The proposed fix in this case is to skip the join() and let the thread return immediately. Bug: https://bugs.openjdk.java.net/browse/

Re: RFR: 8233185: HttpServer.stop() blocks indefinitely when called on dispatch thread

Hi, JDK8  we  don't do join() on "dispatcherThread" in stop(). We need to find out why we introduce the below code. if (dispatcherThread != null) {     try {     dispatcherThread.join();     } catch (InterruptedExc

RFR: 8232513: java/net/DatagramSocket/PortUnreachable.java still fails intermittently with BindException

Hi, The test PortUnreachable closes a DatagramSocket and tries to rebind it to the same port, this causes the test to fail rarely with a BindException (I did 500 test runs and couldn't observe a failure). To decrease the likelihood of this to happen, the fix increases the number of bind retri

RFR: 8233319: Deprecate MulticastSocket methods that operate on java.net.InetAddress

Hi, Please see this fix that deprecates methods of MulticastSocket. These methods either operate on InetAddress instead of NetworkInterface or work with SocketOptions.IP_MULTICAST_LOOP instead of StandardSocketOptions.IP_MULTICAST_LOOP. Bug: https://bugs.openjdk.java.net/browse/JDK-8233319

Re: RFR: 8233319: Deprecate MulticastSocket methods that operate on java.net.InetAddress

Hi, I wonder however if the links to the deprecated setInterface method should remain in the two args joinGroup/leaveGroup, since the behavior is still in effect should you call that method. Agreed, I updated the webrev and specdiff accordingly. http://cr.openjdk.java.net/~jboes/webrevs/82333

Re: RFR: 8232513: java/net/DatagramSocket/PortUnreachable.java still fails intermittently with BindException

Hi Mark, The test has a potential problem,  that is the  socket close can cause the attempted send from server socket to client not to occur. the sock.send() can result in the application data being copied into the kernel and queued for sending.  But the send may not take place immediately. T

RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Hi, Please see this fix that adds support for non-default file systems to the HttpClient. More specifically, the change is in RequestPublishers.FilePublisher where an UnsupportedOperationException is thrown if a java.io.File cannot be obtained. The exception is now caught and a function is us

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Hi Anthony, Thanks for your comments. For distinguishing the non-default filesystem case, an alternative to using the try-catch block is an if-else block with the same check as is done in Path::toFile:     if (path.getFileSystem() == FileSystems.getDefault()) Path::toFile can be overridden s

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Thanks for the review, Chris. After running further httpclient tests, I had to adjusted the exception handling of an existing test, RelayingPublishers. I also added a check in FilePublisher::createInputStream to throw if the path is of a directory. Updated webrev: http://cr.openjdk.java.net

Re: RFR JDK-8240921: Minor correction to HttpResponse.BodySubscribers example

Hi Rahul, The fix looks good to me. Cheers, Julia

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Hi Daniel, We should try to call Path::toFile first - whether there is a security manager or not. In the case where that succeeds, we can use new FileInputStream(), otherwise, we use Files.newInputStream. It's unfortunate that new FileInputStream() and Files.newInputStream() use different sets

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Hi Amy, Just a minor comment on the test usage of /othervm/java.security.policy=FilePublisherPermsTest3.policy -Djava.security.manager As jtreg tag-spec [1] suggested:   The setting of the system properties "java.security.manager" and "java.security.policy" in main/othervm actions is also d

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Hi Daniel, * @run testng/othervm/java.security.policy=FilePublisherPermsTest1.policy Does this actually work as expected? I thought the syntax was: @run testng/othervm/policy= I couldn't get the test to run with the latter but noticed that most tests that are run with testng use the 'java.s

8241674 (XS): Fix incorrect jtreg option in FilePublisherPermsTest

Hi, Could someone please review this small fix of a recently pushed test? The option to extend the policy file has to be 'java.security.policy' instead of 'policy' -  this was discussed on this mailing list but then miraculously ignored by myself... Bug: https://bugs.openjdk.java.net/browse/

Re: Java 14 - Change in InetSocketAddress.toString() behaviour seems to be causing issues

Hi Jaikiran, By the way, keeping aside the breaking nature of this change, the current javadoc, I think doesn't reflect what the current implementation returns for unresolved addresses. The javadoc states: "If the address is unresolved, || is displayed in place of the address literal." Not

RFR: 8237470: HttpResponse.BodySubscriber::ofFile throws UOE with non-default file systems

Hi, We recently added support for non-default file systems to the HttpClient on the sending side. This fix expands the support to the receiving side. More specifically, the change is in ResponseBodyHandlers.PathBodyHandler and ResponseSubscribers.PathSubscriber. In both cases, an Unsupported

RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due to missing FilePermission

Hi, The tests in java/net/httpclient/PathSubscriber don't grant certain file permissions to test library classes. The tests succeed by chance when the compiled library classes are placed under ${test.classes}, but occasionally they fail, depending on which test target compiles the library fir

Re: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due to missing FilePermission

Hi, Chris and I reviewed the build configuration that leads to the changing location of the library classes. The @library tag, which builds classes implicitly in the test class directory, has been supplemented with explicit @build tags for the required library classes. This way, these classes

Re: Fix for Javadoc errors in java.base

Hi Vipin, Thanks for providing this fix, I'm happy to sponsor your change. To complete the review, we still need someone to green light the remaining changes below. I'm looping in net-dev and security-dev to have a look. Bug: https://bugs.openjdk.java.net/browse/JDK-8251542 Webrev: http://cr

Re: Fix for Javadoc errors in java.base

Hi, The two changes below still need to be reviewed. Any takers? Cheers, Julia --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 23:55:41.953638446 +0530 +++ new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafa

RFR: 8245309: Re-examine use of ThreadLocalCoders in sun.net.www.ParseUtil

Replaced the use of ThreadLocalCoders with regular non-caching CharsetEncoder and added a benchmark to confirm that there is no performance impact. - Commit messages: - Replace ThreadLocalCoders and add benchmark Changes: https://git.openjdk.java.net/jdk/pull/170/files Webrev: htt

Re: RFR: 8245309: Re-examine use of ThreadLocalCoders in sun.net.www.ParseUtil

On Tue, 15 Sep 2020 09:49:36 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/sun/net/www/ParseUtil.java line 181: >> >>> 179: CharBuffer cb = CharBuffer.allocate(n); >>> 180: CharsetDecoder dec = UTF_8.INSTANCE.newDecoder() >>> 181: .onMalformedInput(Codin

Re: RFR: 8245309: Re-examine use of ThreadLocalCoders in sun.net.www.ParseUtil

On Tue, 15 Sep 2020 09:31:16 GMT, Aleksey Shipilev wrote: >> Replaced the use of ThreadLocalCoders with regular non-caching >> CharsetEncoder and added a benchmark to confirm that >> there is no performance impact. > > test/micro/org/openjdk/bench/java/net/ThreadLocalParseUtil.java line 65: > >

Re: RFR: 8245309: Re-examine use of ThreadLocalCoders in sun.net.www.ParseUtil

On Tue, 15 Sep 2020 09:40:06 GMT, Alan Bateman wrote: >> test/micro/org/openjdk/bench/java/net/ThreadLocalParseUtil.java line 61: >> >>> 59: Class c = Class.forName("sun.net.www.ParseUtil"); >>> 60: MH_DECODE = LOOKUP.findStatic(c, "decode", >>> methodType(String.class, String.c

Re: RFR: 8245309: Re-examine use of ThreadLocalCoders in sun.net.www.ParseUtil [v2]

> Replaced the use of ThreadLocalCoders with regular non-caching CharsetEncoder > and added a benchmark to confirm that > there is no performance impact. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: fix typo in test an

Re: RFR: 8245309: Re-examine use of ThreadLocalCoders in sun.net.www.ParseUtil [v2]

On Tue, 15 Sep 2020 09:51:27 GMT, Daniel Fuchs wrote: >> Julia Boes has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix typo in test and cleanup benchmark > > Changes requested by dfuchs (Reviewer). Upda

Re: RFR: 8245309: Re-examine use of ThreadLocalCoders in sun.net.www.ParseUtil [v3]

> Replaced the use of ThreadLocalCoders with regular non-caching CharsetEncoder > and added a benchmark to confirm that > there is no performance impact. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: make lookup local va

Integrated: 8245309: Re-examine use of ThreadLocalCoders in sun.net.www.ParseUtil

On Tue, 15 Sep 2020 08:53:35 GMT, Julia Boes wrote: > Replaced the use of ThreadLocalCoders with regular non-caching CharsetEncoder > and added a benchmark to confirm that > there is no performance impact. This pull request has now been integrated. Changeset: e0cf0232 Author: J

Re: RFR: 8255675: Typo in java.net.HttpURLConnection

On Mon, 23 Nov 2020 11:01:35 GMT, Michael McMahon wrote: > What is the effect if this change is integrated as is (from the master > branch)? The normal procedure is to merge from a separate branch. @anupamdev20 note the bot comment above, pushing from your master branch will diverge it. You ca

RFR: JDK-8241995: Clarify InetSocketAddress::toString specification

This change clarifies the InetSocketAddress::toString specification, which was recently updated to reflect an implementation change [1]. The specification is not changed, but it is enhanced with two examples and some more verbiage, as per earlier suggestions on the net-dev mailing list [2][3].

Re: 8241995: Clarify InetSocketAddress::toString specification

Hi Jaikiran, I just created a PR, taking into consideration your suggestion: https://github.com/openjdk/jdk/pull/2357 https://mail.openjdk.java.net/pipermail/net-dev/2021-February/015298.html Regards, Julia From: net-dev on behalf of Jaikiran Pai Date: Tuesday, 2 February 2021 at 15:06 To: C

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification

On Tue, 2 Feb 2021 16:14:10 GMT, Michael McMahon wrote: >> This change clarifies the InetSocketAddress::toString specification, which >> was recently updated to reflect an implementation change [1]. The >> specification is not changed, but it is enhanced with two examples and some >> more verb

Integrated: JDK-8241995: Clarify InetSocketAddress::toString specification

On Tue, 2 Feb 2021 15:55:40 GMT, Julia Boes wrote: > This change clarifies the InetSocketAddress::toString specification, which > was recently updated to reflect an implementation change [1]. The > specification is not changed, but it is enhanced with two examples and some > more

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification [v2]

mailing list [2][3]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8225499 > [2] https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013776.html > [3] https://mail.openjdk.java.net/pipermail/net-dev/2021-February/015297.html Julia Boes has updated the pull request increment

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification [v2]

On Wed, 3 Feb 2021 14:19:27 GMT, Alan Bateman wrote: >> Julia Boes has updated the pull request incrementally with one additional >> commit since the last revision: >> >> small adjustment > > src/java.base/share/classes/java/net/InetSocketAddress.java line 387:

Re: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v7]

On Mon, 21 Dec 2020 08:19:08 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > co

Re: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8]

On Mon, 8 Feb 2021 14:40:16 GMT, Weijun Wang wrote: >> Andrey Turbanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes in Apache Santuario > >

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8]

On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov wrote: >> This fours tests pass without problems, when I run them separately. >> >> ## sun/security/tools/jarsigner/TimestampCheck.java >> ## sun/security/tools/keytool/DefaultOptions.java >> ## sanity/client/SwingSet/src/ColorChooserDemoTest.ja

RFR: 8261750: Remove internal class sun.net.www.MimeLauncher

This change removes sun.net.www.MimeLauncher, a package-private class that is no longer used. The sun.net.www package is exported to java.net.http and jdk.jartool. The only public access point to a MimeLauncher instance is sun.net.www.MimeEntry::launch, which is not called anywhere in those two

Re: RFR: 8261750: Remove internal class sun.net.www.MimeLauncher

On Tue, 16 Feb 2021 10:09:08 GMT, Daniel Fuchs wrote: >> This change removes sun.net.www.MimeLauncher, a package-private class that >> is no longer used. >> >> The sun.net.www package is exported to java.net.http and jdk.jartool. The >> only public access point to a MimeLauncher instance is >

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov wrote: > 8080272 Refactor I/O stream copying to use > InputStream.transferTo/readAllBytes and Files.copy Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? https://github.com/openjdk/jdk/pull/

Integrated: 8261750: Remove internal class sun.net.www.MimeLauncher

On Mon, 15 Feb 2021 18:30:58 GMT, Julia Boes wrote: > This change removes sun.net.www.MimeLauncher, a package-private class that is > no longer used. > > The sun.net.www package is exported to java.net.http and jdk.jartool. The > only public access point to a MimeLaunc

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - >> have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746

RFR: 8262935: Add missing logging to sun.net.httpserver.ServerImpl

Small fix to add logging to catch blocks where it was previously missing. - Commit messages: - add logging Changes: https://git.openjdk.java.net/jdk/pull/2808/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2808&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK

Integrated: 8262935: Add missing logging to sun.net.httpserver.ServerImpl

On Wed, 3 Mar 2021 10:55:12 GMT, Julia Boes wrote: > Small fix to add logging to catch blocks where it was previously missing. This pull request has now been integrated. Changeset: b8178553 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/b8178553 Stats: 6 lines

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - >> have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - >> have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746

RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable

The fix makes the map in sun.net.httpserver.UnmodifiableHeaders unmodifiable by wrapping it in an unmodifiable view. - Commit messages: - fix imports - Merge branch 'master' into 8263506 - fix UnmodifiableHeaders impl - add initial test Changes: https://git.openjdk.java.net/jdk/

Re: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable

On Tue, 16 Mar 2021 14:30:39 GMT, Michael McMahon wrote: >> The fix makes the map in sun.net.httpserver.UnmodifiableHeaders unmodifiable >> by wrapping it in an unmodifiable view. > > src/jdk.httpserver/share/classes/sun/net/httpserver/UnmodifiableHeaders.java > line 60: > >> 58: m

Re: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable [v2]

> The fix makes the map in sun.net.httpserver.UnmodifiableHeaders unmodifiable > by wrapping it in an unmodifiable view. Julia Boes has updated the pull request incrementally with two additional commits since the last revision: - wrap List with unmodifiable map and update test - remo

Re: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable [v2]

On Mon, 22 Mar 2021 16:36:55 GMT, Daniel Fuchs wrote: >> I guess this presumes that no reference to `headers` escapes? Can that be >> assumed? > > Yes - it's private - and that wasn't a problem before - was it? The problem > was the put method that still put things into the map - and that will

Re: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable [v2]

On Mon, 22 Mar 2021 16:41:10 GMT, Daniel Fuchs wrote: >> Actually, I just noticed that the `List`s are still modifiable. The >> constructor might have to create an intermediate `Map>` >> with unmodifiable Lists and then you create an unmodifiable Map from that. >> >> As regards the comment ab

Re: Re: New candidate JEP: 408: Simple Web Server

Hi Krzysztof, Is there a plan to change the package name? I always thought that com.sun.* package was for old internal code and I assume I'm not the only one. the simple server builds on the existing API in the com.sun.net.httpserver package, which was added in JDK 1.6. At that time, the conven

Re: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable [v3]

> The fix makes the map in sun.net.httpserver.UnmodifiableHeaders unmodifiable > by wrapping it in an unmodifiable view. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: move constructor call in ExchangeImpl and fix inden

Re: [External] : Re: Re: New candidate JEP: 408: Simple Web Server

Hi Zheka, On 05/04/2021 16:09, Zheka Kozlov wrote: > Can we put at least new classes to some java.* package (SimpleFileServer, > HttpHandlers, Request)? For example, java.net.httpserver. The new classes extend/implement/build upon the existing abstractions in jdk.httpserver, they have a clear AP

Re: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable [v4]

> The fix makes the map in sun.net.httpserver.UnmodifiableHeaders unmodifiable > by wrapping it in an unmodifiable view. Julia Boes 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: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable [v3]

On Thu, 1 Apr 2021 14:08:47 GMT, Michael McMahon wrote: >> Julia Boes has updated the pull request incrementally with one additional >> commit since the last revision: >> >> move constructor call in ExchangeImpl and fix indentation > > LGTM I included a nu

Re: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable [v5]

> The fix makes the map in sun.net.httpserver.UnmodifiableHeaders unmodifiable > by wrapping it in an unmodifiable view. Julia Boes 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: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable [v3]

On Tue, 6 Apr 2021 13:12:46 GMT, Julia Boes wrote: >> LGTM > > I included a null check in the constructor to account for null values of > `List`, which `Headers` allows. Fixed the indentation. > > Testing: Tier 1-3 all clear. It turns out I wasn't right in the last

Re: RFR: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable [v6]

> The fix makes the map in sun.net.httpserver.UnmodifiableHeaders unmodifiable > by wrapping it in an unmodifiable view. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: assign unmodHeaders instead of original h

Integrated: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable

On Tue, 16 Mar 2021 14:19:09 GMT, Julia Boes wrote: > The fix makes the map in sun.net.httpserver.UnmodifiableHeaders unmodifiable > by wrapping it in an unmodifiable view. This pull request has now been integrated. Changeset: 214d6e21 Author: Julia Boes URL:

RFR: 8265123: Add static factory methods to com.sun.net.httpserver.Filter

Add two static factory methods to com.sun.net.httpserver that facilitate the creation of pre- and post-processing Filters: `public static Filter beforeResponse(String description, Consumer filterImpl) {}` `public static Filter afterResponse(String description, Consumer filterImpl) {}` ---

Re: RFR: 8265123: Add static factory methods to com.sun.net.httpserver.Filter [v2]

ption, > Consumer filterImpl) {}` Julia Boes has updated the pull request incrementally with one additional commit since the last revision: update specs and add test - Changes: - all: https://git.openjdk.java.net/jdk/pull/3468/files - new: https://git.openjdk.java.net/jdk/pul

Re: RFR: 8265123: Add static factory methods to com.sun.net.httpserver.Filter

On Tue, 13 Apr 2021 15:39:17 GMT, Julia Boes wrote: > Add two static factory methods to com.sun.net.httpserver.Filter that > facilitate the creation of pre- and post-processing Filters: > > `public static Filter beforeResponse(String description, > Consumer filterImpl) {}` &

Re: RFR: 8265123: Add static factory methods to com.sun.net.httpserver.Filter [v3]

ption, > Consumer filterImpl) {}` Julia Boes has updated the pull request incrementally with one additional commit since the last revision: fix empty response body - Changes: - all: https://git.openjdk.java.net/jdk/pull/3468/files - new: https://git.openjdk.java.net/jdk/pul

Re: RFR: 8265123: Add static factory methods to com.sun.net.httpserver.Filter [v2]

On Mon, 26 Apr 2021 14:25:50 GMT, Julia Boes wrote: >> Add two static factory methods to com.sun.net.httpserver.Filter that >> facilitate the creation of pre- and post-processing Filters: >> >> `public static Filter beforeResponse(String description, >> Consu

Re: RFR: 8265123: Add static factory methods to com.sun.net.httpserver.Filter [v4]

ption, > Consumer filterImpl) {}` Julia Boes has updated the pull request incrementally with one additional commit since the last revision: update specs and small fix in test - Changes: - all: https://git.openjdk.java.net/jdk/pull/3468/files - new: https://git.openjdk.java.ne

Re: RFR: 8265123: Add static factory methods to com.sun.net.httpserver.Filter [v3]

On Mon, 26 Apr 2021 17:27:13 GMT, Julia Boes wrote: >> Add two static factory methods to com.sun.net.httpserver.Filter that >> facilitate the creation of pre- and post-processing Filters: >> >> `public static Filter beforeResponse(String description, >> Consu

Re: RFR: 8265123: Add static factory methods to com.sun.net.httpserver.Filter [v5]

ption, > Consumer filterImpl) {}` Julia Boes has updated the pull request incrementally with one additional commit since the last revision: some more spec updates and small test cleanup - Changes: - all: https://git.openjdk.java.net/jdk/pull/3468/files - new: https://git.open

Re: RFR: 8265123: Add static factory methods to com.sun.net.httpserver.Filter [v6]

ption, > Consumer filterImpl) {}` Julia Boes 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 ten additional commits since the last revision: - updat

Integrated: 8265123: Add static factory methods to com.sun.net.httpserver.Filter

On Tue, 13 Apr 2021 15:39:17 GMT, Julia Boes wrote: > Add two static factory methods to com.sun.net.httpserver.Filter that > facilitate the creation of pre- and post-processing Filters: > > `public static Filter beforeResponse(String description, > Consumer filterImpl) {}` &

RFR: 8266897: com/sun/net/httpserver/FilterTest.java fails intermittently with AssertionError

The tests for `afterHandler` filters expect the filter operation to happen before the assertion. Very rarely this is not the case, the calling thread reads the response before the filter operation is executed, so the test value is not set before it is asserted. This fix uses a `CompletableFutur

Integrated: 8266897: com/sun/net/httpserver/FilterTest.java fails intermittently with AssertionError

On Mon, 17 May 2021 09:53:06 GMT, Julia Boes wrote: > The tests for `afterHandler` filters expect the filter operation to happen > before the assertion. Very rarely this is not the case, the calling thread > reads the response before the filter operation is executed, so the test va

RFR: 8267262: com/sun/net/httpserver/Filter improve API documentation of static methods

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 resp

Re: RFR: 8267262: com/sun/net/httpserver/Filter improve API documentation of static methods [v2]

nt receiving the response. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: add bug id to test - Changes: - all: https://git.openjdk.java.net/jdk/pull/4085/files - new: https://git.openjdk.java.net/jdk/pull/4085/fi

Re: RFR: 8267262: com/sun/net/httpserver/Filter improve API documentation of static methods [v3]

nt receiving the response. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: address PR comment: change wording - Changes: - all: https://git.openjdk.java.net/jdk/pull/4085/files - new: https://git.openjdk.java.net/j

Re: RFR: 8267262: com/sun/net/httpserver/Filter improve API documentation of static methods [v3]

On Wed, 19 May 2021 10:21:02 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 >> `Filt

  1   2   3   >