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.
I was just working on some simple Java class, no dependencies, in its own j2seproject using JDK 1.5. After a while, for no apparent reason, Fast Import stopped working; trying to import "URI" I would only get some weird class inside Xerces (not java.net.*), and for "FileFilter" I could select the proper import (javax.swing.filechooser.*) but then nothing was actually imported. Meanwhile, of course the log file fills up with errors.
Created attachment 16368 [details] Log excerpt
In 040720, JDK 1.5.0 b58.
As a nice postscript: I then tried Tools > Re-scan Project Classpaths to recover. About ten minutes later when it had finished (!) I noticed an InvalidObjectException, which now is thrown every time I save the file I was working on. I guess I need to shut down the IDE, delete my cache, and start up again.
Created attachment 16369 [details] Exception now thrown every time I save the file
Shutting down and deleting the cache and restarting *did* help for a while. Then I changed the JDK for the project to 1.4.2_04 (from the default platform, 1.5.0 b58) and immediately started getting exceptions again. Bad, too - could not run the project with F6 because the IDE thought the main class was not set.
Created attachment 16376 [details] More exceptions from MDR during my next IDE session, with a cleaned-out var/cache/mdrstorage/
3 problems here: a) Inconsistent storage. (1 != 0) b) Neither re-scan nor autorecovery helped -> P2 c) changing platform from default 1.5.0 b58 to 1.4.2_04 caused problems in MDR
This looks like a parser problem (based on the exception in the first log excerpt). If you see gjast or javac somewhere on a stacktrace please attach the file in the state it was when you got the exception. Otherwise we can hardly reproduce it. Btw. I believe re-scan did help - the IOE problem after re-scan/switchinig platform/autorecovery is a separate issue (in fact several issues already filed - it should disappear after restart except for the case when the autorecovery needs to be involved again and again because of some parser/scanner error - no need to delete storages).
Created attachment 16396 [details] The class in its finished state
Well I have attached the class in its finished state. Of course I cannot exactly remember what it looked like when I was editing it. Anyway if there start to be parser errors thrown to console that I am not aware of, and only later (after I have edited some more) is a visible exception thrown, there is no chance of providing a snapshot of the file at the exact time the parser failed. Suggest perhaps that the parser keep a snapshot of the text of any edited class that it fails badly on, and either print it to console right then, or save it in memory and print it in case you start getting inconsistent storage problems. Otherwise it is very difficult to supply you with accurate data for bug reports, especially when I am trying to concentrate on writing my own code and may not be paying attention to how well or poorly code completion etc. is working.
I understand. I don't blame you. I was just trying to explain that it is hard for us to fix this kind of bugs without the source file that reproduced them. Writing the files that caused problems to the parser to the log is a great idea. But I am not sure if there are no legal problems with it (one may then accidentally attach ide log containing some secret sources without being aware of it). Console should probably be fine, but the shell usually wraps lines which may in fact change the file that caused the problem. Maybe we could dump the source into a separate file in var/log directory and say that in log/console (e.g. "Error in parser. Problematic source dumped to $userdir/var/log/sourcedump001.txt"). What do you think?
"Maybe we could dump the source into a separate file in var/log directory and say that in log/console (e.g. "Error in parser. Problematic source dumped to $userdir/var/log/sourcedump001.txt"). What do you think?" - yes, nice idea; leaves the user in control of what to report. Should probably limit number of such dumps (to 1 or 5 or something); if you get a lot of errors you don't want your log dir filling up with copies of your sources. I assume that normal syntax errors in your source code that the parser correctly detects and marks as errors would not trigger this debug mode - only actual problems in the parser (with either valid or invalid source code).
Source-dump added. Dumps goes to {userdir}/var/log/source[12345].dump files. Checking in src/org/netbeans/modules/javacore/parser/ASTProvider.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/parser/ASTProvider.java,v <-- ASTProvider.java new revision: 1.13; previous revision: 1.12 done Processing log script arguments...
IndexOutOfBoundsException is from gjast code. Reassigning to Tom Ball.
Appears fixed with latest build -- no log exceptions, java.net.URL correctly found.
Jesse can you, please, verify this issue? Thanks.
Probably impossible for me to verify.
No way to verify = closed.
Reorganization of java component