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.
Sometimes when I have unused imports I'll press Cmd-Shift-i to clean up the imports -- and often I'll then get compiler errors. When I look at the diffs I notice that I suddenly have import statements like this: import java.lang.Boolean; import java.lang.Void; This then causes my compilation to fail. I haven't worked out exactly how to reproduce this in a small test case, but in the most recent case where this happened, I had a JavaFX class which implemented a Java interface. I think the JavaFX Imports Fixer should make sure it never tries to import any of the basic java.lang. types -- "Boolean" and "Void" should be left unspecified in the source such that the JavaFX compiler handles it correctly (since these signatures often map to primitives, say "boolean", instead of (in this case) Boolean.
Not sure what could be causing this - the fix imports operations adds only those type names which are marked as unresolvable by the compiler. So it seems that the compiler marks java.lang.* types as unresolvable, for whatever reason. The other thing is that I was not able to reproduce it - I've tried various code snippets (event with implementing a java interface) but with no success :( If you are able to provide a code snippet which reliably turns this bug on, plz, attach it here end reopen this issue.
Steps to reproduce: - Create Space JavaFX class ---------------- Space.fx ------------------ package javafxapplication15; public class Space { public function run(){ } } --------------------------------------------- - Create NewtonSpace JavaFX class ---------------- NewtonSpace.fx ------------------ package javafxapplication15; public class NewtonSpace extends Space{ override function run() { } } --------------------------------------------- - Fix imports in the NewtonSpace.fx file The result is: ------------------------------------- package javafxapplication15; import java.lang.Void; public class NewtonSpace extends Space{ -------------------------------------
Thanks for the example. I was able to pinpoint the problem and fix it. Basically, javafxc, for some reason fails to provide a symbol for the tree representing a built-in typename using the API even if the information is there. Working around this problem by directly accessing the symbol information circumventing the API ... http://hg.netbeans.org/javafx/rev/0749f7c9e191
Should the compiler issue be created as well?
Yes, you can create a javafxc issue. I just didn't feel like spending more time in creating an automated test case for the compiler than working the issue around :(
Compiler issue http://javafx-jira.kenai.com/browse/JFXC-4287
The issue is still reproduced in build NetBeans-JavaFX-Soma: #221 Apr 15, 2010 12:00:58 AM
The TypeClass contains a corresponding Identifier (not sure if that's a general rule or not) and the Identifier suffers from the same problem as the TypeClass - it can not resolve the type element for the built-in types. Working around ... http://hg.netbeans.org/javafx/rev/923b5722fb38
verified in NetBeans-JavaFX-Soma: #227