On Mon, 27 Apr 2026 21:49:23 GMT, Sergey Bylokhov <[email protected]> wrote:
> How the "JEditorPane.getAccessibleContext" is updated if the editorKit and/or
> document was updated?
Each call to `JEditorPane.getAccessibleContext()` may update the current
accessibleContext field. This method reads:
public AccessibleContext getAccessibleContext() {
if (getEditorKit() instanceof HTMLEditorKit) {
if (accessibleContext == null || accessibleContext.getClass() !=
AccessibleJEditorPaneHTML.class) {
accessibleContext = new AccessibleJEditorPaneHTML();
}
} else if (accessibleContext == null || accessibleContext.getClass() !=
AccessibleJEditorPane.class) {
accessibleContext = new AccessibleJEditorPane();
}
return accessibleContext;
}
When it replaces the old `accessibleContext` there is no observable event or
uninstall method. It's just discarded.
> How we will swap AccessibleJEditorPaneHTML/AccessibleJEditorPane based on
> editorKit and clean all that listeners?
This PR is not attempting to clean *all* the listeners. I would love it if we
had a `AccessibleJEditorPane.uninstall()` method, but that feels like scope
creep given the original complaint this PR is trying to resolve.
This PR currently caches the `JEditorPaneAccessibleHypertextSupport` as a
client property in the JComponent. That way if AccessibleContext X is replaced
by AccessibleContext Y: it will continue using the same
JEditorPaneAccessibleHypertextSupport.
We check make sure the hypertext support object is still relevant, and we
discard it if it is outdated (and remove its DocumentListener):
if (axText != null && axText.doc != getDocument()) {
axText.doc.removeDocumentListener(axText);
axText = null;
}
So we are trying to uninstall the JEditorPaneAccessibleHypertextSupport when
possible, but this PR isn't trying to account for other listeners.
Does this speak to your question, or is there a specific set of steps you'd
like to me to express as a unit test?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30401#discussion_r3150630549
