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.

Bug 30971 - Implement swappable JAR handlers
Summary: Implement swappable JAR handlers
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
Depends on:
Blocks: 22322 22508 71524
  Show dependency tree
Reported: 2003-02-11 19:03 UTC by Jesse Glick
Modified: 2008-12-23 08:34 UTC (History)
5 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

My idea how should packages contract look like. (1.88 KB, patch)
2003-02-13 15:00 UTC, Petr Nejedly
Details | Diff
My changes to CLs for "shared knowledge" (45.82 KB, patch)
2003-10-13 16:31 UTC, Petr Nejedly
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-02-11 19:03:30 UTC
Core's class loaders and other module system stuff
should work through an abstraction layer that
handles accesses to module JARs. This will permit:

1. Unit tests checking e.g. that certain kind of
class loads or resource lookups do not make
excessive leaf calls. Just run with a dummy
testing manager with a counter that mimics a
couple of JARs.

2. Some other module system unit tests could be
made simpler, perhaps - no need to create physical
JARs for every test.

3. Manifest cache could be abstracted into a cache
of "hot" resources from JARs - META-INF/*,
**/*layer*.xml, **/, etc.

4. Could more easily measure impact of JAR
mmap'ing on cold start time, hot start time, and
RSS, by swapping in a test non-JAR manager. Or,
impact of multiple little JARs, by swapping in a
manager that loads from a merged megajar.

5. If desirable, could implement more radical
optimizations such as loading resources from a
cached binary store.

6. Manager can have a method to get a quick
package list for a JAR - alternate
ProxyClassLoader implementations could exploit
this to precompute a domain cache rather than
waiting for cache hits. Impl with JAR files may or
may not be fast enough - can be measured.
Comment 1 Jesse Glick 2003-02-11 19:24:48 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
Comment 2 Petr Nejedly 2003-02-13 15:00:21 UTC
Created attachment 8936 [details]
My idea how should packages contract look like.
Comment 3 Petr Nejedly 2003-02-13 15:02:50 UTC
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?
Comment 4 Jesse Glick 2003-02-13 16:02:40 UTC
Comment 5 Jesse Glick 2003-02-26 22:04:47 UTC
Not for 3.5.
Comment 6 Petr Nejedly 2003-03-04 13:06:58 UTC
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
Comment 7 Jesse Glick 2003-09-25 16:32:34 UTC
I'm not actively working on this.
Comment 8 Petr Nejedly 2003-10-13 16:31:33 UTC
Created attachment 11842 [details]
My changes to CLs for "shared knowledge"
Comment 9 Petr Nejedly 2003-10-13 16:34:20 UTC
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...
Comment 10 Jesse Glick 2005-05-31 15:40:28 UTC
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.
Comment 11 _ rkubacki 2005-05-31 15:48:42 UTC
There is an issue #41028 about using ByteBuffer to speed up class loading
Comment 12 Jesse Glick 2008-02-24 21:36:44 UTC
Things have changed, e.g. #753dd88065e7. There is now a cache system. There is also ModuleFactory. Probably enough for now.
Comment 13 Jaroslav Tulach 2008-02-25 17:46:52 UTC
Btw. #3 - is also implemented or ready to be - we have Stamps infrastructure that takes care of caches