On Tue, 12 Sep 2023 12:34:12 GMT, Christopher Sahnwaldt <d...@openjdk.org> wrote:
>> In >> https://github.com/openjdk/jdk/commit/b8af3d50192f8bc98d83f8102f0fd1989f302e32 >> the weak reference was accidentally changed from a field to a local >> variable, which means that the PropertyChangeListener keeps a strong >> reference to executorService, which is a resource leak > > Christopher Sahnwaldt has updated the pull request incrementally with one > additional commit since the last revision: > > SwingWorkerExecutorLeakTest.java: use AppContext.getAppContext() instead of > SunToolkit.createNewAppContext() to create AppContext, set necessary system > properties Maybe this issue is a non-issue. Someone who knows how `AppContext` is currently used should check. The resource leak only occurs when `AppContext.dispose()` is called. I don't know if this method is still called anywhere in the JDK. (A [search for `dispose`](https://github.com/search?q=repo%3Aopenjdk/jdk%20path%3asrc%20dispose&type=code) produces too many results.) Each `AppContext` is related to a thread group, and `AppContext.dispose()` must be called in a thread group that is not the same or a descendant of the `AppContext`'s thread group – otherwise `dispose()` does nothing and throws. But `AppContext.getAppContext()` usually creates an `AppContext` in the root thread group, which means that `dispose()` can never succeed. `AppContext.getAppContext()` only creates `AppContext` in the current thread group if at least one of the system properties `javaplugin.version` and `javawebstart.version` is set, and `javafx.version` is set. See [AppContext.getAppContext()](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/AppContext.java#L313). I don't know in which situations that condition is true. A comment in the code says "Swing inside JavaFX case". ------------- PR Comment: https://git.openjdk.org/jdk/pull/15081#issuecomment-1715660040
