[bill.burke]

I'm not sure truezip is the answer. From what I've seen, they have only wrapped java.io stuff to make it threadsafe.

BTW, this wasn't limited to JarFile problems. Also had problems with regular FileHanders being read through the vfsfile:/ URL indirection.

[bill.burke]

also, for truezip we would have to really reengineer and dive into their codebase to layer the VFS on top of it. Currently, MOST of it is married to java.io.File implementations and not URL based. Their nested jar support extracts jars into temporary files. None of it that I saw allows you to provide a InputStream or URL as the implementation is based fully based on RandomAccessFiles.

[starksm64]

Can we extract the zip decompression code from truezip to create our own JarFile easily?

In terms of the URL issues, our long term view has been to write our own class loader to get away from the jdk implementation details. Running efficiently in any jdk means dealing with their implementation.

[bill.burke]

I found out why it was so slow...

I wasn't caching for every possible scenario. The RepositoryClassLoader was looking for a non-existent class (like it always does) and the VFS was recreating the JarFiles for each child while looking for the non-existent Child.

[slaboure]

What if you add an additional BufferedInputStream to the stream? in my AOP test (reading classfilles annotations), it had a dramatic impact.