Re: [jboss-dev] Scanning jars for package capabilities
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