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.
Open an existing project with a .fx file and as quickly as you can, click down the project, Source Packages, package, xxx.fx tree. This will sometimes yield an exception (see below), as will typing in new code very quickly. Test platform is Fedora FC9 64 bit SMP kernel, Netbeans 6.5.
Jim, are you running with or without assertions enabled (check your $NETBEANS_HOME/etc/netbeans.conf for -J-ea). We always run with assertions disabled (have deleted the -ea switch from the conf file). The exception sent via mail was java.lang.AssertionError: attempt to reuse JavaCompiler at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:733) at com.sun.tools.javafx.main.JavafxJavaCompiler.backEnd(JavafxJavaCompiler.java:67) at com.sun.tools.javafx.main.JavafxCompiler.backEnd(JavafxCompiler.java:813) at com.sun.tools.javafx.main.JavafxCompiler.compile2(JavafxCompiler.java:766) at com.sun.tools.javafx.main.JavafxCompiler.generate(JavafxCompiler.java:797) at com.sun.tools.javafx.api.JavafxcTaskImpl.generate(JavafxcTaskImpl.java:266) at org.netbeans.api.javafx.source.JavaFXSource.moveToPhase(JavaFXSource.java:268) at org.netbeans.api.javafx.source.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:131) at org.netbeans.api.javafx.source.CompilationController.toPhase(CompilationController.java:72) at org.netbeans.modules.javafx.source.scheduler.CompilationJob.run(CompilationJob.java:186) at java.util.concurrent.Executors $RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor $Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor $Worker.run(ThreadPoolExecutor.java:907) [catch] at java.lang.Thread.run(Thread.java:619)
I do see an error when I type gibberish quickly, but it is not the same error. I get: NullPointerException at org.netbeans.lib.javafx.lexer.v4Lexer.mINVALIDC It tends to happen most frequently when ( { or [ is used. I'll attach the full error.
Created attachment 70116 [details] exception text
Tested using FX Cont trunk build 191 on NB6.5:
Ah! Turns out I can get this new error anytime I type the \
It also happens for: ` ~ ! @ ^ &
Make sure that you do not confuse these two issues. Perhaps you should open a new bug for the abort when typing an unused character? The reuse of the java compiler is a different issue. Jim --------------------- Thanks! I have created a new issue for the NPE I have listed. http://www.netbeans.org/issues/show_bug.cgi?id=147654
I am sorry to repeat the question but can you please answer this: Jim, are you running with or without assertions enabled (check your $NETBEANS_HOME/etc/netbeans.conf for -J-ea)? We always run with assertions disabled (have deleted the -ea switch from the conf file).
I don't turn off assertions as I need to see them for the compiler and so on. I wold have thought that turning off assertions is just masking issues?
Right - it is masking issues that we have no control over. The official policy for NetBeans builds is that the dev builds are running with assertions enabled but the final release has the assertions disabled not to bother the end user. By disabling the assertions we test the status that will the very end user see. Please keep in mind that if the compiler fails to deliver something we just catch the exceptions and try to offer some functionality without that information, e.g. no code completion, less colorful source code but are still able to edit/save/compile/run/debug the source code for the end user. I am putting also pnejedly to the Cc: of this issue - he is responsible for actual invoking the javafxc so he might also cast some opinion on this. In the ideal world I would also like to run with the assertions enabled but our job is to deliver something usable for the end user and showing the exceptions is the last think the end user is interested in when editing his source. Of course fixing the errors would be even nicer but before you came to this project our average time to fix an issue in the compiler was rather high ;-)
Jim, are you still able to reproduce it? I am not on: Product Version: NetBeans Platform 6.5 (Build 200903060201) Java: 1.6.0_12; Java HotSpot(TM) Client VM 11.2-b01 System: Windows XP version 5.1 running on x86; Cp1251; ru_RU Userdir: C:\Projects\NetBeans\trunk\javafx\build\testuserdir lowering priority since end user won't see it, since -J-ea is disabled.
I don't seem to be getting this error any more, so I guess it can be closed. I think it might still be there though unless someone has done something to avoid reusing the compiler object specifically. Jim
OK, thanks.
verified