On Mon, 25 Dec 2023 12:27:59 GMT, Artem Semenov <aseme...@openjdk.org> wrote:
>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line >> 799: >> >>> 797: for (int i = 0; i < count; i++) { >>> 798: TreePath path = tree.getPathForRow(i); >>> 799: Accessible an = >>> createAccessibleTreeNode(tree, path); >> >> I see that you are creating the accessible tree node with reflection calling >> its constructor. Can you just elaborate if it is the only way to get hold of >> it and why getting a tree.getAccessible().getAccessibleChild(i) does not >> work or what kind of problem getting the tree node this way creates? > > A little lower, the access algorithm is implemented in the way you showed. > But to speed things up, I want to avoid recursion through the native and for > this it is easier to initialize those nodes that are present in the tree path > through the constructor. Why do I propose to use reflection? Otherwise, you > will either have to make the constructor of a double-nested class public, or > create a chain of methods that allow you to instantiate this class through a > new call in CAccessibility. I can't say i like the approach but i can accept it as a hotfix to eliminate the situation but only if we create a followup bug to fix it properly - even if it will require a new public accessor to be added to the JTree class that will instantiate the tree node accessibility peer for a given TreePath without the need to use a reflection. Using reflection like this really breaks the encapsulation and logic separation principles introducing the unneeded dependency on the implementation details in the unrelated class. So as a bottom line - i will approve that as a hotfix but the followup bug to properly eliminate the implementation dependency and getting rid of the reflection call to be filled and addressed in the next release. If that will require a CSR - let there be CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17165#discussion_r1450947083