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.
[200407220815], jdk1.4.2_04 -appeared after Alt+Shift+F on java file getASTContext() returned null for: Type 356 :1 java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1064) at org.netbeans.modules.javacore.jmiimpl.javamodel.TransientElement.init(TransientElement.java:50) at org.netbeans.modules.javacore.jmiimpl.javamodel.MetadataElement.initOrCreate(MetadataElement.java:928) at org.netbeans.modules.javacore.jmiimpl.javamodel.PrefixExpressionImpl.initChildren(PrefixExpressionImpl.java:74) at org.netbeans.modules.javacore.jmiimpl.javamodel.TransientElement.init(TransientElement.java:62)
Created attachment 16392 [details] org.netbeans.modules.javacore.jmiimpl.javamodel.TransientElement.init(TransientElement.java:50)
*** Issue 46267 has been marked as a duplicate of this issue. ***
Lukasi, do you have the class where fix all imports were invoked?
Created attachment 16416 [details] class for reproduction
i was able to reproduce with attached class. the testForImports.java was in 'Functional Test Packages' in relevant package. Open it in Editor and Alt+Shift+F
Thanks Lukas, it is what we were looking for. Reassigning to Tom to evaluate. ASTree.getASTContext() returns null for ParserTokens.INT_LIT.
Why is this code working on a ScannerToken instead of an actual tree? If you look at org.netbeans.lib.java.parser.ScannerToken, its constructors pass a null ASTContext, which is what is then returned. If you were working on a literal tree element from gjast, the toString output would look different. I think the bug is much higher, where somewhere a token is fetched (using ASTContext.getToken()) and then passed as an ASTree. Regardless of how the team likes to treat tokens and trees as the same, they really are very different.
No, it is not true that we fetch it by calling ASTContext.getToken(). If you look at stacktrace, the parameter tree is obtained at PrefixExpressionImpl:74 by calling tree.getSubTrees()[1].
Cc'ing ME developers, they have other scenarios how to reproduce.
That's cool, maybe these ME engineers will share with me how to reproduce the error, as I cannot. I need to know where to find any additional ME modules that might be needed, and a source file where this happens. Please reopen this issue when that information is available.
Tom, use prefix expression in your source code and use negative integer value, e.g. if (something == -1) {...
Okay, I see the problem: if you look at org.netbeans.lib.java.parser.ScannerToken's constructors, you'll see that tokens can only be created with "null" for the ASTContext. Later, the old parser sets the ASTContext, but does so using a package-private method I don't have access to. So I'll add a constructor which accepts an ASTContext from my scanner.
ASTContext now set in tokens.
Reopening, it looks like the fix caused a problem. See Issue 48914
I've tried to reproduce a described behaviour for continuous build 20040914-0837 and I wasn't successfull. I've tried three cases, press Alt_Shift_F on an attached file, source with negative integer value and on the projects/projectui/src/org/netbeans/modules/project/ui/ProjectChooserAccessory.java file (from #46267 issue). I would mark this issue as verified, but I'll wait for resolved status by a developer.
*** Issue 48821 has been marked as a duplicate of this issue. ***
v
Reorganization of java component