I see that both clearXXX methods are called in setNextSibling, so you remove them here as redundant. But I don't understand why you remove the null check if (ast != null), could you explain please?

Ok so lets suppose if ast is null. then
in current code the process stop at if (ast != null).

But if not then my updated code is

        final DetailAstImpl sibling = nextSibling;
        final DetailAstImpl astImpl = (DetailAstImpl) ast;

        if (sibling != null) {
            astImpl.setNextSibling(sibling);
        }

        setNextSibling(astImpl);

ast is assigned to astImpl and it is used at the end of method setNextSibling(astImpl); (This is the only usage of last in whole method) know in setNextSibling(astImpl); (where atImpl is null and we are passing null to setNextImpl)

     public void setNextSibling(DetailAST nextSibling) {
        clearBranchTokenTypes();
        clearChildCountCache(parent);
        this.nextSibling = (DetailAstImpl) nextSibling;
        if (nextSibling != null && parent != null) {
            ((DetailAstImpl) nextSibling).setParent(parent);
        }
        if (nextSibling != null) {
            ((DetailAstImpl) nextSibling).previousSibling = this;
        }
    }

here

know to set the parent of this node and the previous sibling of the node in both the if condition it is assigned that nextSibiling != null so it will never be the node of the tree (for surety I have updated the test case to check the childcount of parent you can check testAddNextSibling2)and not affect code or generate any kind of null pointer exception.

How about this logic:

        if (sibling != null) {
            astImpl.setNextSibling(sibling);
        }

It is a potential NPE here when sibling is not null but astImpl is null. Is this a possible outcome?

Yes, you are right. I am really sorry, I don't know how I have missed this.

This may lead to major breaks in future

I will update in next push

done

if (ast != null)

logic retrieves