Children may be out of order after adding a statement

[andrecsilva]

Children may be out of order after adding a statement

[jlerbsc]

When JP assigns the parent node to the new node, it adds it to the list of children of the parent node, regardless of the order.

The children of a node are not necessarily of the same type, as is the case when you consult the list of statements in a block. For example, when you consult the list of children of a class declaration, there may be a name and one or more method declarations. It wouldn't make sense to insert a new method before or after the class name. You can consider that the list of children is not ordered.

[andrecsilva]

@jlerbsc

Thanks for clarifying this, but the problem with considering the list of children as unordered is that it is used for tree traversal. So the actual order of the tree doesn't match the (expected) order in the code.

Consider the following snippet is appended from the previous one.

    System.out.println("----------------------------------------------------");
    System.out.println(blockStmt.findAll(VariableDeclarator.class));
    System.out.println("----------------------------------------------------");
    blockStmt.walk(TreeTraversal.PREORDER, n -> System.out.println(n));
    System.out.println("----------------------------------------------------");

This will output:

    ----------------------------------------------------
    [b = 2, c = 3, a = 1]
    ----------------------------------------------------
    {
        int a = 1;
        int b = 2;
        int c = 3;
    }
    int b = 2;
    int b = 2
    b = 2
    int
    b
    2
    int c = 3;
    int c = 3
    c = 3
    int
    c
    3
    int a = 1;
    int a = 1
    a = 1
    int
    a
    1

As we can see, the order from both walk and findAll differ from the one we can expect from looking at the printed code for the tree. Now, let's reparse the tree and check the traversal order.

    var newTree = StaticJavaParser.parse(cu.toString());
    
    var newBlockStmt = newTree.findFirst(BlockStmt.class).get();
    System.out.println(newBlockStmt.findAll(VariableDeclarator.class));
    System.out.println("----------------------------------------------------");
    newBlockStmt.walk(TreeTraversal.PREORDER, n -> System.out.println(n));
    System.out.println("----------------------------------------------------");

    ----------------------------------------------------
    [a = 1, b = 2, c = 3]
    ----------------------------------------------------
    {
        int a = 1;
        int b = 2;
        int c = 3;
    }
    int a = 1;
    int a = 1
    a = 1
    int
    a
    1
    int b = 2;
    int b = 2
    b = 2
    int
    b
    2
    int c = 3;
    int c = 3
    c = 3
    int
    c
    3
    ----------------------------------------------------

Ideally, this operation is idempotent, meaning, the new tree is the same as the old one to some degree (i.e. some things like node ranges will eventually differ), but the order differs despite both trees generating the same code.

For my use case, having a coherent order is important for calculating variable scopes and tracking assignments. Of course, there are workarounds (reparsing the tree will solve this, as shown above), but this still feels like more like a bug other than a design choice.

[jlerbsc]

In the second case, the result is what you would expect, because the parsing is performed on the printable version of the modified unit compilation, and the printable version makes an internal call to the PrettyPrinterVisitor class, which browses the statements of the block (versus the list of child nodes).

Given that the children of a node are not necessarily of the same type and that nodes do not necessarily have a range (for example, nodes that have just been added), you should not use the findAll method to obtain an ordered list of children.

[jlerbsc]

I'm closing this exit because we've answered your question. But I can reopen it if you have any further questions.