On Mon, 15 Jan 2024 09:49:53 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> With my CSR hat on, JDK-8301341 should never have made the changes it did >> without going through a CSR request. We have been bitten by this kind of >> problem many times. Unless a public method is specified to utilise another >> public method, we should never implement one public method in terms of >> another (non-final one) due to the overriding problem. Backporting such a >> change to 21u is then potentially very damaging. > >> With my CSR hat on, JDK-8301341 should never have made the changes it did >> without going through a CSR request. We have been bitten by this kind of >> problem many times. Unless a public method is specified to utilise another >> public method, we should never implement one public method in terms of >> another (non-final one) due to the overriding problem. > > JDK-8301341 was a big update, a lot of refactoring to hollow out SQ and it > was just an oversight that we didn't spot the methods now use an overridable > method. It's something to always look out for in the collections area, just > missed here. Thanks for the reviews @AlanBateman and @DougLea ------------- PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1892838717
