Optimizing BeanInfo Lookup

Introduction

Currently VW (Insync) uses the VW Project's compile time classpath entries as the basis for building the designtime URL Classloader. This means that the class path contains URL's:

• all regular libraries of the project
• all the component libraries (COMPLIBS)
• all the theme libraries
• JDK stuff
• App server stuff
• direct jar/zip file references
• build/classes folder

Out of which only the

• all the component libraries
  • classpath volume
  • visual-web-designtime volume
• all the theme libraries
  • classpath volume

are really required for designtime.That is because the designtime Classloader also delegates to one of the applicable ClassLoaderProvider - (J2EE14 or J2EE15) modules's Classloader. That Classloader in turn delegates to most of the required J2EE library providing modules through module dependency.

This means that all the other stuff:

• JDK stuff (Actually the JDK stuff needs to be handled correctly. That is because the project's associated JDK may be different from the JDK of the NetBeans IDE. This is a potential problem.)
• App server stuff
• direct jar/zip file references

is unnecessarily in the set of URLs of the Classloader which may slow down class and beaninfo lookups. There may be occasional cases where some complib classes depends on additional jars. Those cases need to be handled specially.

Proposal

My proposal is simple (may be not so simple). Instead of using the whole compile time class path of the project as the basis for designtime Classloader class path only use:

• all the component libraries (COMPLIBS)
  • classpath volume
  • visual-web-designtime volume
• all the theme libraries
  • classpath volume

There is a slight complication due to the use of EJB and Web Services related functionality because in those cases complibs are not used. Instead archive references are used for runtime as well as designtime jar. In fact, IMHO, the addition of designtime jars to the project's compilation classpath is a mistake. That is because the classes from designtime jar become part of the code completion set - which is wrong. There are couple of solutions to this:

• EJB and Web Services support uses the COMPLIB mechanism for referring to the runtime and designtime jars. This may require significant changes to the code generation though. This solution will not be implemented.
• Instead of adding the archive references to designtime jars to the project - add them to a special property in the nbproject/project.properties file - cp.extra.visual-web-designtime (say!) - in the project.properties file. The URL's specified in this property will be added to the designtime Classloader. Similarly the runtime jars will be also appended to a special property in the nbproject/project.properties file - cp.extra.visual-web-compile. The values of these properties will be jar file paths separated by java.io.File.pathSeparator char. This is a simpler solution and will be implemented.

Plus a mechanism for the user to explicitly add any additional jars/libs to the designtime classpath in those rare circumstances when the complibs are not self contained. This may involve some UI in the Projert Properties dialog.

Status

I sent a jar with these modifications to Winston. According to him there is a definite improvement.And this is without the optimization of ignoring Woodstock and Braveheart libraries as they are available through the J2SE14ClassLoaderProvider and J2SE14ClassLoaderProvider respectively.