David M. Lloyd wrote:
On 01/05/2010 10:40 AM, Bill Burke wrote:
>
> Ales Justin wrote:
>> Perhaps this can be solved by custom (+ temp) deployer,
>> which would create capabilities from those exports,
>> but would just say import-all for imports.
>>
> No shit shirlock...Especially when thats what is being done now.
>
> Again, optimizing this algorithm doesn't matter if jars/directories are
> being browsed.
What do you mean by "browsed"? If you're going to access any file in a
JAR, you need to scan the (unordered) ZIP directory anyway. Better to do
it one time and cache it so files can be looked up on an O(1) basis. And
once you've done that, why not use that data for other purposes?
A simple test of using ZipInputStream vs. URLClassLoader to find a
resource within jacorb.jar.
ZipInputStream: 256ms.
URLClassLoader: 5ms.
URLClasLoader is obviously using some other mechanism to find things.
public void testZipStream() throws Exception
{
URL url =
Thread.currentThread().getContextClassLoader().getResource("jacorb.jar");
ZipInputStream zis = new ZipInputStream(url.openStream());
Map<String, ZipEntry> map = new HashMap<String, ZipEntry>();
ZipEntry entry = null;
while ((entry = zis.getNextEntry()) != null)
{
map.put(entry.getName(), entry);
}
}
public void testClassLoader() throws Exception
{
URL[] urls =
{Thread.currentThread().getContextClassLoader().getResource("jacorb.jar")};
URLClassLoader cl = new URLClassLoader(urls);
URL url =
cl.getResource("org/jacorb/orb/portableInterceptor/RequestInterceptorIterator.class");
System.out.println(url);
}
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com