This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 96387 - TreePathHandle.resolve() returns null for statement tree path handle
Summary: TreePathHandle.resolve() returns null for statement tree path handle
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jan Becicka
URL:
Keywords:
Depends on:
Blocks: 90451
  Show dependency tree
 
Reported: 2007-02-23 01:05 UTC by _ deva
Modified: 2007-05-22 19:01 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Test module to reproduce the bug (15.22 KB, application/octet-stream)
2007-02-23 01:07 UTC, _ deva
Details
Unit test for TreePathHandle (6.89 KB, text/plain)
2007-05-22 19:01 UTC, _ tboudreau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ deva 2007-02-23 01:05:04 UTC
If you create a TreePathHandle for a statement tree in one user action task 
and then attempt to resolve the obtained tree path handle in another user 
action task returns null
Comment 1 _ deva 2007-02-23 01:07:15 UTC
Created attachment 38848 [details]
Test module to reproduce the bug
Comment 2 _ deva 2007-02-23 01:11:56 UTC
Build and install the attached module and follow these steps to reproduce the 
bug
1) Open the file TestClass.java which is part of the project
2) Select Refactor|Resolve Tree Path Handle
You will notice the assertion I have put

When I debugged this issue, I found that in TreePathHandle.resolve() the 
KindPath for resolved TreePath is [IDENTIFIER, MEMBER_SELECT, 
METHOD_INVOCATION, EXPRESSION_STATEMENT, BLOCK, METHOD, CLASS, 
COMPILATION_UNIT] whereas expected TreePath is [EXPRESSION_STATEMENT, BLOCK, 
METHOD, CLASS, COMPILATION_UNIT], therefore the method returns null
Comment 3 _ tboudreau 2007-05-15 04:25:59 UTC
Any workaround for how you can take a list of StatementTrees from one parse and
match them to the matching ones from another?  I'm attempting an Extract Method
refactoring, and I can't figure out how to remove the lines that have been
extracted into the new method.
Comment 4 _ tboudreau 2007-05-21 21:53:08 UTC
Any ETA on a fix for this?  It's blocking some work I'm doing in
contrib/refactorings, which in turn is blocking writing some tutorials on how to
write refactorings.
Comment 5 Jan Becicka 2007-05-22 10:31:04 UTC
Checking in TreePathHandle.java;
/cvs/java/source/src/org/netbeans/api/java/source/TreePathHandle.java,v  <-- 
TreePathHandle.java
new revision: 1.10; previous revision: 1.9
done
Comment 6 _ tboudreau 2007-05-22 17:36:03 UTC
Sorry, this is still broken.  I just tried taking the hacks out of
contrib/refactorings.  The following code fails on the first assertion when
passed a list of StatementTrees.  This is with a build using version 1.10 of
TreePathHandle:

    public static List <TreePathHandle> toHandles (TreePath parent, List <?
extends Tree> trees, CompilationInfo info) {
        List <TreePathHandle> result = new ArrayList <TreePathHandle>
(trees.size());
        for (Tree tree : trees) {
            TreePath path = TreePath.getPath(parent, tree);
            TreePathHandle handle = TreePathHandle.create(path, info);
            result.add (handle);
            assert handle.resolve(info) != null : "Newly created TreePathHandle
resolves to null"; //NOI18N
            assert handle.resolve(info).getLeaf() != null : "Newly created
TreePathHandle.getLeaf() resolves to null"; //NOI18N            
        }
        return result;
    }
Comment 7 _ tboudreau 2007-05-22 19:00:14 UTC
Never mind, apparently the TreePath I passed in was bad.

I'll attach a unit test for TreePathHandle I created - perhaps it will be useful
to avoid any regression.
Comment 8 _ tboudreau 2007-05-22 19:01:46 UTC
Created attachment 42656 [details]
Unit test for TreePathHandle