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.
Summary: | Implement swappable JAR handlers | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Module System | Assignee: | Jesse Glick <jglick> |
Status: | VERIFIED WONTFIX | ||
Severity: | blocker | CC: | dstrupl, jtulach, pnejedly, rkubacki, ttran |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | TASK | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 22322, 22508, 71524 | ||
Attachments: |
My idea how should packages contract look like.
My changes to CLs for "shared knowledge" |
Description
Jesse Glick
2003-02-11 19:03:30 UTC
Created branch: cvs rtag jar_manager_30971_base core_nowww_1; cvs rtag -b -r jar_manager_30971_base jar_manager_30971 core_nowww_1 Created attachment 8936 [details]
My idea how should packages contract look like.
Because e.g. org.netbeans.modules.debugger package is present in both debuggercore.jar and debuggerjpda.jar, but populated only in debuggercore.jar and we don't want to look for debuggercore classes in the debuggerjpda's classloader, do we? Right. Not for 3.5. BTW: I've tried to implement a ProxyClassLoader that knows full mapping from packages to Set<ProxyClassLoader> (SCL is handled separately) and it seems it works and has potential for speeding up the startup. For now, I just iterate all the jar entries to compute the populated packages (which costs >2000ms) for all NB jars, and the startup is slowed down by about 900ms. If this info is cached (either explicitely noted in manifest, or added only to the manifest cache), we may gain up to ~1200ms I'm not actively working on this. Created attachment 11842 [details]
My changes to CLs for "shared knowledge"
Just for record. My changes that allows shared,cached knowledge of package coverage. Yarda was interested in seeing it and I've nearly lost the sources, so I hope they're safe here :o) The diff may be a bit outdated and contains noise as I've had hard times even to find it on old HDD... Was suggested to use ByteBuffer loading of classes as an optimization. This RFE might also provide a more coherent basis for implementing the module system portion of JNLP support. There is an issue #41028 about using ByteBuffer to speed up class loading Things have changed, e.g. #753dd88065e7. There is now a cache system. There is also ModuleFactory. Probably enough for now. Btw. #3 - is also implemented or ready to be - we have Stamps infrastructure that takes care of caches |