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.
See issue #99294 for background. The initial scan probably can be improved in several directions: -precompiled storage (similar to the precompiled storage in NB5.5) -better interruptibility by runUserActionTask (especially of jar file scanning)
Upgrading this to P1 since this is a severe performance impact on the first usage of any jars for visualweb. For example: - first web project creation for a web project w/ visualweb framework takes 1.5-2 minutes, almost all of which is classpath scanning for the JDK and appserver jars - dynamic adding of libraries is slow, such as during the drag-and-drop of webservices to the visual designer The scanning for known jars (predefined libraries, JDK, etc.) should at least be done at some other time than during project creation or UI manipulation.
It would be very helpful to have this issue addressed in M9 since this is going to be a Preview of NB 6 and if it takes 2 minutes to create a new web project with visual jsf framework with a new userdir, that would be a very bad first impression on NB 6.
Tip: Isn't it possible to run with existing pre-scanned user directory? Run IDE, create j2se project, classes are scanned, close project and exit IDE. Second time when you start netbeans with the same user directory, it looks like first opening and when create project, scan shouldn't be made (or better say, rt.jar shouldn't be scanned). -- We could call it hand-made index. ;-) Just to clarify: I vote to implement this ENHANCEMENT, but I'm afraid nobody will have enough time to finish it till M9 (maybe I'm wrong?) and this seems to solid workaround which can be used in demo. (I didn't try it - I hope I don't miss any point.)
I tried the visual web and the problem is somewhere else. It calls compiler API from the event thread which is the biggest problem and should be resolved anyway. The pre scan of jars may just hide a bit this problem.
I will add an method where you can post the task which will be executed when the scan finished asynchronously outside the event thread,this should make the removal of the java API calls from the event thread simpler. Making the jar scan more interruptable cannot be done in M9 but can be done after it, before JavaOne, in bug fixing period. But I am not sure if it helps you, before the jars are scanned some parts of java infrastructure does not see the jar file data, for example you cannot use ClassIndex, refactoring API.
Actually Tomas is right in his comment - "I tried the visual web and the problem is somewhere else. It calls compiler API from the event thread which is the biggest problem and should be resolved anyway. The pre scan of jars may just hide a bit this problem.". It has been the VW architecture top call the source modeling code on AWT event thread. We need to fix that on our side. This will not be a matter of quick fix and we need time to analyze and fix this. I am afraid we will not be able to implement it by M9. Having said that this Enahancement still makes sense independently and should be implemented. Another simplest Enhancement I would like to see is a simple callback when the scan is finished (and probaly events when it starts and restarts).
I agree with Sandip. This is exactly what I want to do in the M9. The method runWhenInitialScanFinished. I also want to implement this enhancement but it will be not in M9 which ends this week but in the bug fixing phase of M9.
Ability to run task when background scan completes. Checking in apichanges.xml; /cvs/java/source/apichanges.xml,v <-- apichanges.xml new revision: 1.8; previous revision: 1.7 done Checking in nbproject/project.properties; /cvs/java/source/nbproject/project.properties,v <-- project.properties new revision: 1.18; previous revision: 1.17 done Checking in src/org/netbeans/api/java/source/JavaSource.java; /cvs/java/source/src/org/netbeans/api/java/source/JavaSource.java,v <-- JavaSource.java new revision: 1.45; previous revision: 1.44 done Checking in src/org/netbeans/modules/java/source/classpath/GlobalSourcePath.java; /cvs/java/source/src/org/netbeans/modules/java/source/classpath/GlobalSourcePath.java,v <-- GlobalSourcePath.java new revision: 1.8; previous revision: 1.7 done Checking in src/org/netbeans/modules/java/source/usages/RepositoryUpdater.java; /cvs/java/source/src/org/netbeans/modules/java/source/usages/RepositoryUpdater.java,v <-- RepositoryUpdater.java new revision: 1.49; previous revision: 1.48 done Checking in test/unit/src/org/netbeans/api/java/source/JavaSourceTest.java; /cvs/java/source/test/unit/src/org/netbeans/api/java/source/JavaSourceTest.java,v <-- JavaSourceTest.java new revision: 1.11; previous revision: 1.10 done
I have rewritten the BinaryAnalyser to be interruptable on the level of files which may help to visual web. I am testing it and if everything is fine I will integrate it today.
Checking in BinaryAnalyser.java; /cvs/java/source/src/org/netbeans/modules/java/source/usages/BinaryAnalyser.java,v <-- BinaryAnalyser.java new revision: 1.10; previous revision: 1.9 done Checking in RepositoryUpdater.java; /cvs/java/source/src/org/netbeans/modules/java/source/usages/RepositoryUpdater.java,v <-- RepositoryUpdater.java new revision: 1.51; previous revision: 1.50 done
Actually I am not clear on the meaning of "interruptible". Can someone please explain. Also is this going to help the clients that need to access full functionality of Java model or will such clients have to wait anyways? IN that case it may not help VW which uses the Java model in read/write mode at the time of project creation :( Also please see the scenarios described in: http://www.netbeans.org/issues/show_bug.cgi?id=101604 which compares creation of VW project and scenario and Go To type dialog in Web Project with similar set of libraries.
Of course in the time of scanning the java infrastructure cannot provide all the features since they are no data for it. The Go to type (GTT) dialog cannot list the declared types since the IDE does not see them. For the GTT there is some issue that it should show "Wait scan in progress..." like in 5.5. If you need ClassIndex while you opening the project you have to use JS.runWhenScanFinished to wait to the end of initial scan. In the release we will provide pre built caches for rt.jar like in NB 5.5. Maybe you can do something like this for your libs.
This change seems to have helped improves the scenario described in Issue #101604. It is now taking about 1 min 4 secs to open the Designer on the first page of a newly created VW project starting with clean user dir. This use to take 1 min 40 secs.