update jar file with java code

[Chris Uppal]

FamilyNet International Newsgate

From: "Chris Uppal" <[email protected]>

Hmm, if I remember the zip file formant, there's an index and file count
at the beginning of the zip file,

The end.

But in general, the absence of a generic "add this to an existing
archive" seems defective to me. Maybe there's a good reason for it
though.

The only option for "modifying" ZIP files which doesn't amount to making a copy
of the file (with whatever desired changes applied as you do so), is to append
to an existing file. In that case you can overwrite the existing
table-of-contents with the appended file(s), and then recreate the table of
contents. In fact, you can also delete the last N files, but that's not a very
useful operation and in any case depends on being able to truncate a file to a
length other than zero (which is not, IIRC, available on all OSs).

I vaguely remember seeing something about an append operation being
added to the java.util.zip.*; but I can't now recall whether it was just
someone whining in the Bug Parade, or was something concrete planned for an
upcoming release.

-- chris



FamilyNet <> Internet Gated Mail
http://www.familynet-international.org

 

[Mark Space]

FamilyNet International Newsgate

From: "Chris Uppal" <[email protected]>





The end.



The only option for "modifying" ZIP files which doesn't amount to making a copy
of the file (with whatever desired changes applied as you do so), is to append
to an existing file. In that case you can overwrite the existing
table-of-contents with the appended file(s), and then recreate the table of
contents. In fact, you can also delete the last N files, but that's not a very
useful operation and in any case depends on being able to truncate a file to a
length other than zero (which is not, IIRC, available on all OSs).

I vaguely remember seeing something about an append operation being
added to the java.util.zip.*; but I can't now recall whether it was just
someone whining in the Bug Parade, or was something concrete planned for an
upcoming release.

This is good information, but it still all falls under the heading of
"doing something tricky" to a jar, yes? I mean there's no explicit API
that allows one to determine if a given zip or jar file can be modified
with out re-writing the whole archive.

And even if there was, can a jar be modified and then streamed in place?
I think you still have to make a temp file, which can be kinda a pain
on local resources if the jar is very large.

Assuming the answer is "no, a jar can't realistically be streamed in
place, a new file is definitely required," should there be an API to
allow a JAR to be modified and then streamed?

append() might help, but how do you test for "replace a file then stream
it?" A test for isAtEnd() or isModifiableInPlace( String [] ) might be
more helpful. (The latter method would take a list of file names in the
archive, and determine if they form a contiguous block at the end that
can be truncated and replaced.)

Then you still got to be able to stream the modified file without
closing it, which I have no idea how to do....

 

[Chris Uppal]

This is good information, but it still all falls under the heading of
"doing something tricky" to a jar, yes? I mean there's no explicit API
that allows one to determine if a given zip or jar file can be modified
with out re-writing the whole archive.

Correct. But then, there is no API for modifying JAR/ZIP files at all....

A sensible API /might/ include the ability to append new entries to a ZIP file,
which is always possible as an in-place operation, but the Sun stuff currently
does not.

More general replacements would probably be more effort than they are worth --
the API would be complicated, confusing, and error prone, both for the user of
the API and for its implementer. A far better choice would be to expose the
incremental/streaming nature of the ZIP format at the API level, and let the
client programmer work directly with that. The Java implementation is
noticeably less than full-featured, but it does include the basics needed to do
this yourself if you wish.

And even if there was, can a jar be modified and then streamed in place?
I think you still have to make a temp file, which can be kinda a pain
on local resources if the jar is very large.

The ZIP file format is designed for streaming/incremental reading or writing --
e.g you can create a ZIP file, writing it to a tape device or network
connection, without ever seeking backwards. Similarly you can read the
contents of a ZIP file sequentially with no backward seeks (though you do have
to scan the entire file; obviously you cannot make use of the table of contents
to do random-access in this scenario).

The only non-constant space aspect to creating a ZIP file is maintaining an
internal copy of the table of contents which will eventually be written to the
end of the output stream. Theoretically that could be built incrementally by
creating a temporary file on-disk, but in practise there's no reason not just
to keep the data in memory.

Then you still got to be able to stream the modified file without
closing it, which I have no idea how to do....

I can't be bothered to check the details, but the following pseudo-code loop
should copy a ZIP file making modifications as it goes. Note that neither the
entire input, nor the entire output, is held in memory at any one time, and
also note that we never seek backwards in either the input or output streams.
Buffering, error checking, etc are all omitted.

InputStream input = ...
OutputStream output = ...
ZIpInputStream inZip = new ZipInputStream(input);
ZIpOuputStream outZip = new ZipOuputStream(output);

ZipEntry in;
while ((in = inZip.nextEntry()) != null)
{
ZipEntry out = self.replacementFor(in);
if (out == null)
{
// just copy "in"
outZip.putNextEntry(in);
self.copyEntryContents(inZip, outZip);
}
else
{
// write replacement
outZip.putNextEnty(out);
self.writeReplacementContents(in, outZip);
}
inZip.closeEntry();
outZip.closeEntry();
}

inZip.close();
outZip.close();

See the JavaDocs for the details. If you are going to do this kind of thing in
a production environment, then it would probably be a good idea to acquire at
least a basic understanding of the ZIP file format -- in particular the way
that the size, crc, etc, of an entry can be written either before or after the
data itself.

-- chris