On Mon, 2 Nov 2026 02:42:19 GMT, ExE Boss <[email protected]> wrote: >> This resolves the NPE reported in 8395930, and it enhances the preexisting >> test for JDK-8381236 to cover this case. >> >> The failing use case involves an Accessible object where >> `axObj.getAccessibleContext() == null`. Having a `null` AccessibleContext is >> an atypical case, but it is explicitly identified/allowed in the contract >> for `Accessible.getAccessibleContext()`. >> >> Prior to [8381236 >> changes](https://github.com/openjdk/jdk/pull/30578/changes), calling >> CAccessible.getCAccessible(ax) would also fail with a NPE. So in this PR I'm >> proposing preserving that behavior (and documenting it), and moving the null >> check to 8381236's new `disposeRecursively` method. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 74: > >> 72: private static CAccessible getCAccessible(final Accessible a, final >> boolean createIfUndefined) { >> 73: if (a == null) return null; >> 74: AccessibleContext context = a.getAccessibleContext(); > > Suggestion: > > private static CAccessible getCAccessible(final Accessible a, final > boolean createIfUndefined, final boolean returnNullOnNullContext) { > if (a == null) return null; > AccessibleContext context = a.getAccessibleContext(); > if (returnNullOnNullContext && context == null) return null;
This looks structurally OK (I think the unit test will pass), but I don't think I understand the motivation behind it. Your proposed `returnNullOnNullContext ` parameter gives devs the choice: "in this edge case would you rather return null or throw a NPE?" That feels like a weird choice to offer. (Is there a precedent somewhere else in the codebase that works like this?) Thoughts? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33657#discussion_r4452279152
