-
Bug
-
Resolution: Fixed
-
P4
-
8u20, 9
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8085145 | emb-9 | Pete Brunet | P4 | Resolved | Fixed | team |
JDK-8063964 | 8u45 | Pete Brunet | P4 | Resolved | Fixed | b01 |
JDK-8057991 | 8u40 | Pete Brunet | P4 | Closed | Fixed | b08 |
JDK-8069817 | emb-8u47 | Pete Brunet | P4 | Resolved | Fixed | team |
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>() {
@Override
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);
latch.await();
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.
final AccessibleContext ac2=InvocationUtils.invokeAndWait(new Callable<AccessibleContext>() {
@Override
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);
latch.await();
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.
- backported by
-
JDK-8063964 Java Access Bridge, regression, NPE, occurs randomly
-
- Resolved
-
-
JDK-8069817 Java Access Bridge, regression, NPE, occurs randomly
-
- Resolved
-
-
JDK-8085145 Java Access Bridge, regression, NPE, occurs randomly
-
- Resolved
-
-
JDK-8057991 Java Access Bridge, regression, NPE, occurs randomly
-
- Closed
-