EVALUATION
JarInputStream is a sequential input stream which doesn't mean to provide
random access to the input data. Requiring it to be able to find the manifest
at the end of the stream is not reasonable.
Secondly, the manifest file should always be the first entry in a particular
jar file, in fact our jar tool enforces this restriction. Of course, we cannot
prevent other vendors from manually putting the manifest at any other place in a
jar, which is otherwise semantically equivalent. I think if we do want to
support this random access functionality, we should do it somewhere else, either
in the security checking code itself, or by using the ZipFile API with support
of byte range transmission in http1.1 and adding more constructors to ZipFile
class.
###@###.### 1999-08-23
For a remote URL source, JarURLConnection.getJarFile() can be used to
get the locally cached jar file and random access is allowed. This code
can be added to the security checking procedure and the location of the
manifest will not matter any more.
###@###.### 1999-09-03
|