ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32649] - ant-produced jar files don't match those produced by java.util.jar.JarOutputStream
Date Mon, 20 Dec 2004 07:37:46 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32649>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32649





------- Additional Comments From dp@eng.sun.com  2004-12-20 08:37 -------
(In reply to comment #8)
> We can handle a delay, after all, we have no schedule for the next release.
> One question: are you trying to look for a magic number at an offset in the
> binary, or are you parsing the zip file?
> 
> A magic number pattern is most like classic unix exe lookup, but is inordinately
> brittle against different legitimate layouts of ZIP files. You should really be
> recognising the PK DWORD at the beginning of the file and say 'this is a zip,
> lets look inside it *using the zip algorithm* and see if it has a manifest. 
> 
> Presence of a valid manifest is what should really determine if a jar is
> executable. If that aint there, you wont know which class to execute, etc, etc.
> Since we do produce valid manifests if asked to, that should all work. 

Thanks for your patience.  The algorithm as it stands is as follows:

The kernel decides to use the 'javaexec' file executor based on magic number
(same as with ELF and interpreted files, like #!... ).  Based on the magic
number (PK\003\004), the javaexec module is invoked.  My reading of the code is
as follows:

1. Read the 30 byte file header.
2. Look for 'PK\003\004' at the beginning.  If not, fail.
3. Let XOFF = 30 (file header size) + Size of the first file's name
   (stored at offset 26).  So, if the first file is META-INF/, XOFF = 9.
4. Let XOFF_END = XOFF + Size of the first file's extension.  Normally this
   would be zero, but in this case, the jar tool seems to set it in the
   archive to '4'.
5. Scan the buffer starting at XOFF and ending at XOFF_END for the
   byte pattern: 0xcafe.  If not found, fail.
6. Find and invoke the Java runtime environment on the file.

I can only assume that the answer to: "why not scan the whole file for the
manifest file" is that this would be rather expensive, although I'm not
sure.  If you mean that we should also unzip the manifest file and parse it--
I think the answer is that we try not to sink that level of complexity into
the kernel.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message