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.
Rewrite MultiURLClassLoader to (1) not be a URLClassLoader, but open JARs directly for speed; (2) find the packages in each module immediately and never need to guess which package holds a class, unless it can only be found in some non-MURLCL parent.
I was already looking at this issue, trying to write a new ClassLoader for jars. I have (for the beginning) abadoned the idea of pre-parsing jars for all packages (it wasn't that slow, ~600ms for all modules, but it doesn't count Manifest processing and will not scale good. (Yes, when I came up with this idea, I was thinking about tons of CNFEs, EmptyStackEs and PrivilegedActionEs, but not with the way modules should behave - only few classes at the beginning)) My later idea was to have: 1) ProxyClassLoader that will handle loading from more parent loaders (do the dirty work of fooling JDK's ClassLoaders idea), but won't load anything itself (have the methods defined, but empty) 2) Have a JarClassLoader that will handle loading from a list of jars and their extensions. Ideas for speedup: 1. don't use CNFEs in the inner signaling. When SystemClassLoader asks around all the OneModuleClassLoaders, it will save some time 2. (Have to be discussed) Ask the faster classloaders before the slower ones, i.e. preferr MUCLs over unknown. 3. (Maybe) Have a map of the known packages shared between MUCLs. There will be less virgin package openings and less redundant informations. Every MUCL can then check whether a CL from the map is in his parents (accessibe) or not (surely CNFE, can't have one package in two loaders at once) Maybe it would be best to have both implementations and compare their performance/implications.
1) Implemented in org.netbeans.core.modules.ProxyClassLoader & org.netbeans.core.modules.JarClassLoader 2) doesn't seem to be faster, abadoned
Target milestone -> 3.3.1.
I think we've already done our best on this.
Yes, I think so. #3 is not trivial; see the method shouldDelegateResource: I don't know how a domain cache could be shared in the presence of this method, without a lot of work.
resolved before year ->closed