On Mon, 22 Apr 2024 18:52:00 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
>> If I write a test case "test multiple requests without closing" - and add >> that test case to earlier JDK versions, it will fail every time - with no >> setting that would allow it to work. >> >> So trying to protect earlier bad code that couldn't possibly have worked >> doesn't seem right to me. I am fairly certain that the only existing code >> that will break are the incorrect tests cases that exist in the JDK. There >> can be no existing handlers in the wild that will break with these changes. >> >> I feel like I am taking up too much of your time with these discussions. I >> was only trying to fix the jdk version for others (using the knowledge I >> gained in the robaho impl). >> >> A back-ported change could guard the changes - they are fairly trivial - but >> I'll let others undertake that. >> >> The api >> [docs](https://docs.oracle.com/en/java/javase/11/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpExchange.html) >> already state: >> >>> When the response body has been written, the stream must be closed to >>> terminate the exchange. >> >> so I don't think back-porting as is an issue. I have never encountered an >> impl of an api that tries to work around improper use of the api. > > Let me add some background: > https://www.hyrumslaw.com/ > https://xkcd.com/1172/ > https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility > > Every time we make an observable behavioral change, we need to decide if we > can make it without any additional documentation, or if a release note or a > CSR is necessary. > > In this case we have 2 failing tests with that change. As you correctly > pointed out, these tests are failing because of bugs in their implementation. > But then, these tests show that the change is already impacting existing > code. With that in mind, a release note will be necessary. This is not for > us; this is for the users who may upgrade to the latest version and find that > their tests are failing. > > The product changes are fine in their current form. Could you fix the failing > tests? I’ll update the PR to fix the tests. I understand the need for backwards compatibility- it’s one of the prime reasons Java is awesome - but in this situation the tests are validating that 1+1=3 and I don’t think anyone wants that. You’re assuming that changing the validation of the test cases means the potential for breaking code - as I’ve stated before I don’t think that’s possible in this case - because the test cases were never verifying code you would see in a production system. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1575406288
