JDK-8057977 : Java Access Bridge, regression, NPE, occurs randomly
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.accessibility
  • Affected Version: 8u20,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-09-09
  • Updated: 2015-06-04
  • Resolved: 2014-09-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u40Fixed 9 b33Fixed
Since 8u20 there are NPEs coming from the JAB code, most likely due to the fix for JDK-8037477.  The NPE happens in many different scenarios but the one that can cause it quicker than the rest is to press Alt+F to bring up the menu system and then left/right arrow between the first pulldown and the second pulldown.  The problem appears to be due to a mismatch between the reported number of accessible children and the actual number of accessible children.  In com.sun.java.accessibility.AccessBridge._getVisibleChild there is this code:

            final AccessibleContext ac2=InvocationUtils.invokeAndWait(new Callable<AccessibleContext>() {
                public AccessibleContext call() throws Exception {
                    Accessible a = ac.getAccessibleChild(idx);
                    return a.getAccessibleContext();
            }, ac);

That callable is later called in invokeAndWait this try/catch:

            try {
                SunToolkit.postEvent(targetAppContext, event);
                T result = wrapper.getResult();
                updateAppContextMap(result, targetAppContext);
                return result;
            } catch (final Exception e) {
                throw new RuntimeException(e);

If there is no accessible for one of the items being iterated through in _getVisibleChild the prior code block will throw an NPE on the line with a.getAccessibleContext();  That NPE will be caught in the second code block and rethrown out to the console.

A null check could be added to the first block but this should not be needed because there is a call to getAccessibleChildrenCount prior to the first block and each of the children should have a valid accessible.

This is not an issue with 8u11.
On 9 I was able to get the failure when using JAWS. It happened when navigating through the file menu. It's fairly hard to reproduce. Sometimes I see it consistently when doing this: open the menu system and then press alt+tab to move focus away from SwingSet2. However it's dependent on the invocation of SS2, i.e. you might not see it again after stopping and starting SS2. Then again you might. It happens about 50% of the time. This scenario also was able to cause the failure in 8u about 10% of the time.

Tried it on fresh 9 build and the failure doesn't happen as often, but when it did it was during the call to _getVisibleChild. And the scenario changes; it happens either when moving focus away from SwingSet2 (alt+tab) or exiting SS2.

The NPEs are not seen with JAWS or NVDA, only Ferret. In that case this is not a critical issue.

Starting with a fresh 8u clone there is an NPE but at a different spot, getAccessibleSelectionFromContext. The same issue with not checking for NULL accessible exists though.