#224710 - ClassPathProviderImpl.getJsStubs is slow yet called many times for single indexed file

Bug:
http://netbeans.org/bugzilla/show_bug.cgi?id=224710

Description: To be able to show in JavaScript code completion 'JS 
plaform' for elements location instead of the real location (inside JS 
stubs files) of core files, #isPlatform() method was introduced which 
detects whether the file lies within signature files location or not. 
However the location of JS stubs is got every time using IFL instead of 
caching which leads to the bad performance.

Impact assessment: Since the method is currently called by files 
indexing the JavaScript editor usage is really much slowed down.

Risk assessment: The locations of found JS stubs files are just stored 
into static field, almost no risk.

The fix was written by phejl, reviewed by me and issue verifed by vriha.

Fix: http://hg.netbeans.org/web-main/rev/b29f4389304d

Thanks for the review,
Martin.


On 11/22/2011 08:31 PM, Martin Fousek wrote:
> Bug:
> http://netbeans.org/bugzilla/show_bug.cgi?id=204427
>
> Description: When the maven customizers were generalized and fixed, 
> there started to appear deadlocks by saving maven project customizer 
> when some Web Framework was included. Deadlock is caused by creating 
> new file under project mutex write lock. The way how to fix that was 
> widely discussed in the issue and calling project extension in AWT EDT 
> was considered as the safest solution.
>
> Impact assessment: every first addition of Web framework into Maven 
> based project finishes with deadlock
>
> Risk assessment: changes are just maven.j2ee module related and it 
> affects just the saving of customizer panels of this module, very low 
> risk
>
> The fix was reviewed by mjanicek and verified by jskrivanek.
>
> Fix:
> hg.netbeans.org/web-main/rev/f9f9e02059de
>
> Thanks for the review,
> Martin.
>