United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-5046178 : JarInputStream doesn't return Manifest object

Details
Type:
Bug
Submit Date:
2004-05-12
Status:
Resolved
Updated Date:
2013-04-30
Project Name:
JDK
Resolved Date:
2013-04-30
Component:
core-libs
OS:
generic
Sub-Component:
java.util.jar
CPU:
generic
Priority:
P3
Resolution:
Won't Fix
Affected Versions:
6
Fixed Versions:

Related Reports
Relates:
Relates:

Sub Tasks

Description
Attempting to get a Manifest object off a JarInputStream returns null,
while the JarFile returns it just fine.

Here is the test program (in comments), and the jar file in question attached.
###@###.### 2004-05-12

                                    

Comments
Given the nature of the JarInputStream (it's possible it's a non-seekable stream), there is no practically possible solution to locate/read the manifest without consuming the stream data, if the manifest is not the first/second entry (which is currently the assumption of JarInputStream spec/implementation, if the manifest entry is required/seeked) in the stream. Closed as "will not fix" for now.
                                     
2013-04-30
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-06-14
WORK AROUND

Reorganize the jar file so that the manifest always comes first.
This will happen automatically if the jar command is always used to
create the jar file non-incrementally, i.e. without using the -u flag.

###@###.### 2004-05-14
                                     
2004-05-14
EVALUATION

JarInputStream has to be able to work on a non-seekable stream,
so implementing a method to get the Manifest is in general, impossible,
at least if the stream has not been exhaustively read.

The way that JarInputStream handles this is by assuming that a manifest,
if present, must occur at the beginning of the jar file,
preceded only by an entry for the META-INF directory itself.

It might be a good idea to set the manifest if it is encountered while
scanning the jar file, but in any case, because the requested functionality
cannot be made to work perfectly, the docs should be updated to reflect
the lowered expectations that users should have.

###@###.### 2004-05-14
                                     
2004-05-14



Hardware and Software, Engineered to Work Together