Bug 99923

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.