jboss-development

I don't view the ZipFile api as flexible enough as it requires a 
java.io.File and nested jars. In addition all jdk implementations have a 
native component that has tended to introduce locking and memory faults. 
That is why I believe we need a pure java jar/zip file implementation 
that addresses these limitations.

David M. Lloyd wrote:
> But folks, consider this.  By doing this scanning by default, this 
> means there's yet another hoop the user must jump through in order to 
> use the most performant configuration (in this case, bypassing the 
> scanning).
>
> All that said though, I think this whole issue would become moot if we 
> eliminate using the JAR streaming API from VFS.  If we instead used 
> the ZipFile API exclusively, "traversing the JAR" would amount to 
> scanning the keys of a HashMap, never mind all the other possible 
> issues with streaming zipfiles that I've raised elsewhere.
>
> - DML

_______________________________________________
jboss-development mailing list
[EMAIL PROTECTED]
https://lists.jboss.org/mailman/listinfo/jboss-development