On Wed, 27 Nov 2024 06:26:17 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>> Inflater/Deflater date from JDK 1.1 so I think there is some risk to adding >> a final no-arg close method. I understand that a corpus analysis has been >> done, and the intention of making it final is for subclasses to know which >> method to override, but it doesn't take from the possibility that it might >> break subclasses developed years ago. If it goes ahead as reviewed, then >> we'll to do some outreach and be prepared to back out this change in the >> event that breakage is reported before GA. > > Hello Alan, > >> If it goes ahead as reviewed, then we'll to do some outreach and be prepared >> to back out this change in the event that breakage is reported before GA. > > I agree that if the `final close()` causes issues, then backing this change > out and reconsidering a non-final `close()` would be the right thing to do. > Once/if this gets integrated into 24, I will work with the outreach team to > have this change noted in their EA mails. Adding a final close method is both source and binary incompatible so I don't think the CSR can be approved without more justification. So I think the issues of introducing a non-final close should be examined again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1860057566
