On Fri, 12 Jan 2024 11:03:02 GMT, Alan Bateman <al...@openjdk.org> wrote:
> This feels more like a hazard when extending to override behavior. Yeah, this is certainly a potential issue with any subclass-able class. I remember seeing similar before in other areas too. > I think it would be useful to provide a summary on what the override wants to > do, maybe there are better ways to customise by wrapping the LTQ rather than > subclassing. Yeah, and we can likely refactor our code to workaround this change in JDK 22. I added a summary and reproducer in the JIRA, which should help. I'll try to explain a little here. The crux of what the code is attempting to do is to scale the executor to max pool size by refusing tasks if there is the pool is less than the given max, then later intercepting rejections and putting the task on the queue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1888898399
