FitnessViaCleanup

Almost every NetBeans release is dedicated to creation of new functionality. Every release has its own major themes and these dictate the areas where most of the people's work is going to be spend. The goal is to deliver the best and most tempting functionality for our users. As the release schedule is tight and set of features to support almost never-ending, the usual workflow consists of delivering the feature, bugfixing it to an acceptable state, releasing it and then leaving the code in favor of new release, new project and new best and tempting functionality for our users.

This working style serves well in short term and makes NetBeans the "only IDE you ever need", yet in long term it accumulates a lot of little problems in the already released areas that sort of work, but not quite. They are slow, not optimal, buggy, just not slow enough to be high priority bugs, not that bad to require rewrite, not that buggy to deserve real fixing storm.

Yet, thousands of small problems may accumulate and cause significant overall degradation. This happened to NetBeans as well, and it seems the time has come to take a broom and clean the little pieces of the dirt from our IDE floors.

Deprecated APIs

Let's stop using APIs that are already deprecated.

No class means no code

Improve the system to prevent unnecessary loading of classes. Use improvements possible due to introduciton of FitnessViaDeclaration. Prevent slow degradation in FitnessViaWhiteAndBlackList tests caused by poor infrastructure.

Improving buggy subsystems: JAR Cache

Reported as IZ 156330. There is 4500 touches to module JAR files during startup which seems quite ineffective especially when running on cold system. There seem to be these major problems:

A lot of disk touches comes from findExtensionsAndVariants:

java.io.File.isFile(File.java:776)
org.netbeans.Util.findLocaleVariantsWithSuffixesOf(Util.java:118)
org.netbeans.Util.findLocaleVariantsOf(Util.java:99)
org.netbeans.StandardModule.findExtensionsAndVariants(StandardModule.java:329)
org.netbeans.StandardModule.<init>(StandardModule.java:133)
org.netbeans.ModuleFactory.create(ModuleFactory.java:65)
org.netbeans.ModuleManager.create(ModuleManager.java:496)
org.netbeans.core.startup.ModuleList$1.run(ModuleList.java:287)
org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:120)
org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:502)
org.netbeans.core.startup.ModuleList.readInitial(ModuleList.java:166)
org.netbeans.core.startup.ModuleSystem.readList(ModuleSystem.java:262)
org.netbeans.core.startup.Main.getModuleSystem(Main.java:162)
org.netbeans.core.startup.Main.start(Main.java:304)

Can we change the system to scan for module JARs only if the cache missed during classloading? Similar, case is very likely:

java.io.File.exists(File.java:731)
org.netbeans.StandardModule.findExtensionsAndVariants(StandardModule.java:344)
org.netbeans.StandardModule.<init>(StandardModule.java:133)
org.netbeans.ModuleFactory.create(ModuleFactory.java:65)
org.netbeans.ModuleManager.create(ModuleManager.java:496)
org.netbeans.core.startup.ModuleList$1.run(ModuleList.java:287)
org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:120)
org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:502)
org.netbeans.core.startup.ModuleList.readInitial(ModuleList.java:166)
org.netbeans.core.startup.ModuleSystem.readList(ModuleSystem.java:262)
org.netbeans.core.startup.Main.getModuleSystem(Main.java:162)
org.netbeans.core.startup.Main.start(Main.java:304)
org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:110)
java.lang.Thread.run(Thread.java:619)

The other quite frequent touch comes from JarClassLoader constructor and again, shall probably be delayed:

org.netbeans.test.ide.CountingSecurityManager.checkRead(CountingSecurityManager.java:176)
java.io.File.isDirectory(File.java:752)
org.netbeans.JarClassLoader$Source.create(JarClassLoader.java:314)
org.netbeans.JarClassLoader.<init>(JarClassLoader.java:143)
org.netbeans.StandardModule$OneModuleClassLoader.<init>(StandardModule.java:696)
org.netbeans.StandardModule.classLoaderUp(StandardModule.java:629)
org.netbeans.ModuleManager.enable(ModuleManager.java:803)
org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:428)
org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:364)
org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:276)

And finally I can see a bit of URLConnection touches which could probably be eliminated as well, if we correctly implemented BinaryFS.lastModified:

org.netbeans.test.ide.CountingSecurityManager.checkRead(CountingSecurityManager.java:175)
java.io.File.isDirectory(File.java:752)
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:65)
sun.net.www.protocol.file.FileURLConnection.initializeHeaders(FileURLConnection.java:90)
sun.net.www.protocol.file.FileURLConnection.getLastModified(FileURLConnection.java:151)
org.netbeans.core.startup.layers.BinaryFS$BFSFile.lastModified(BinaryFS.java:789)
org.openide.filesystems.MultiFileObject.lastModified(MultiFileObject.java:510)
org.openide.filesystems.MultiFileObject.lastModified(MultiFileObject.java:510)
org.openide.loaders.InstanceDataObject$Ser.instanceOf(InstanceDataObject.java:1214)
org.openide.loaders.InstanceDataObject.instanceOf(InstanceDataObject.java:737)
the call comes either from InstanceDataObject or from
org.netbeans.modules.project.libraries.LibrariesStorage.isUpToDate(LibrariesStorage.java:481)
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo